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The VLX: A Design 
for Serviceability 


he NonStop VLX™ system 
was designed to provide the 
lowest cost of ownership of 
computer systems used for 
large OLTP applications. 
Cost of ownership encom- 
passes all costs associated 
with a system, including: 


« Initial purchase price. 

= Application development. 

= Facilities to house the system. 
= System operation. 

= Service. 


Historically, the cost of service has been a 
significant component of cost of ownership. 

In the past decade, computer vendors typi- 
cally provided service for computer hardware 
at a charge of as much as 12% or more of the 
initial purchase price per year. Assuming a 
$1 million system, this adds up to $600,000 
over the first five years of ownership. 

The Tandem™ NonStop VLX system was 
designed to lower the cost of ownership in 
three ways: 


= Increased system reliability. 

® Accurate fault analysis and remote support 
capability. 

= Simplified service through improved 
packaging. 


This design has reduced the cost of hard- 
ware service contracts on an entry-level 
NonStop VLX system to as little as 3% of the 
system purchase price per year. This article 
describes the features designed into the 
NonStop VLX system to achieve this 
reduction. 


Design 


Maintenance Strategy 

The maintenance strategy that guided the 
design of VLX service and support features 
is the result of an evolutionary process at 
Tandem. The strategy can be summarized 
as follows: 


= Provide a highly reliable system through 
careful component selection and sophisticated 
design technique. 


= Provide continuously available on-line oper- 
ations and diagnostic tools. 


= Constantly monitor all critical system 
resources and the operating environment, and 
log all significant events for further analysis 
and action. 


= Provide highly accurate fault isolation of 
field-replaceable units (FRUSs). 

« Provide the capability to operate and diag- 
nose the system either locally or remotely. 

= Provide a single operator interface for all 
system maintenance activity. 
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Features 

Newly designed system components for the 
NonStop VLX system include the processor, 
interprocessor bus (IPB), fiber-optic extension 
(FOXII™), system cabinets, system power sup- 
plies, and the maintenance and operation 
facility (CHECK). In this article, these compo- 
nents are referred to as the “processor com- 
plex.” The following features were designed 
into the processor complex to implement 
Tandem’s strategy. 


The CHECK Facility. The CHECK facility 
provides continuous monitoring of, and diag- 
nostic access to, the VLX processor complex. 
Its features include: 


# Continuous monitoring of processor com- 
plex components and environment. 


= Detection and reporting of events. 


= Diagnostic access to facilitate analysis of 
events and execution of tests. 


® Operator console. 
= Remote support/operations interface. 


These features are discussed in greater detail 
later in this article. 


Integrated Diagnostics and Fault Analysis. All 
diagnostic functions are integrated with the 
on-line Tandem Maintenance and Diagnostic 
System, or TMDS (Troisi, 1985), which pro- 
vides a single human interface for all mainte- 
nance activities. 

Built-in self-test capabilities in the processor 
improve the diagnostic test coverage and dras- 
tically reduce the test time. 

Automatic fault analysis uses information 
captured and reported at the time an event 
occurs to isolate faulty components without 
requiring tests to be executed. 


Remote Support Capabilities. Integration of 
the NonStop VLX system service and support 
features with the Tandem On-line Support 
Center (OSC) provides remote support capabil- 
ities. An accompanying article, ““Remote Sup- 
port Strategy,” describes the OSC and the 
evolution of remote support at Tandem. 


Error-checking Circuitry. Error-checking cir- 
cuitry in all system components is capable of 
capturing critical information about errors 
that occur and reports this information via the 
CHECK facility for analysis by TMDS fault 
analyzers. It also protects the integrity of the 
customer’s data. 


Reliable Components. Highly reliable compo- 
nents, including VLSI circuits, were used in 
the design. 


Failure Protection. Use of sparing, error cor- 
rection, and retry and error recovery tech- 
niques increase availability of system 
resources. 


Packaging. System packaging was designed to 
improve the mean-time-to-repair, and to allow 
error-free identification, removal, and replace- 
ment of all assemblies. 

The rest of this article describes: 
= The CHECK facility. 
= Error detecting, reporting, and recovery. 
= The built-in self-test features. 
= Automatic fault analysis. 


= The system features designed for ease of 
service and basic operations. 
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Figure 1. 

Simplified view of the 
NonStop VLX CHECK 
facility. 


Temperature 


Power supplies 


CHECK Facility 


The NonStop VLX system includes distributed 
hardware, software, and firmware that pro- 
vide basic system operation, monitoring, and 
diagnostic facilities. Collectively, these com- 
ponents are referred to as the CHECK facility. 
(See Figure 1.) 


Overview 


Operations. The CHECK facility provides the 
mechanisms needed to perform basic system 
operations such as cold-loading, setting sys- 
tem time at cold load or power failure recov- 
ery, resetting processors, taking memory 
dumps, obtaining system status, and notifying 
the operator of fault conditions. 

Access to these facilities is provided through 
a terminal, a system control panel, a remote 
communications port (via a modem), and 
applications programs running on-line (e.g., 
TMDS). 


Monitoring. The CHECK facility monitors the 
processor complex components and its envi- 
ronment via interfaces to the VLX processors, 
FOXII components, power supplies, batteries, 
and fan and temperature sensors. 

The CHECK facility performs all voltage, 
current, temperature, and rotational measure- 
ments needed to identify abnormal power and 
environmental conditions. Each I/O and CPU 
cabinet is continually monitored. The inlet 
and outlet air temperature of each cabinet is 
monitored. (See Figure 2.) Each fan is moni- 
tored for its rotational speed, allowing fan 
failures to be reported immediately. Power 
supplies are monitored for correct operation, 
including DC levels, peak levels, periodic 
and random deviation (such as ripple) values, 
and ground and voltage return shifts. (See 
Figure 3.) Loss of AC input power is detected 
by the power supplies and reported to the 
respective processors, to allow the processor 
state to be saved to memory. Memory is pro- 
tected by battery power until AC input power 
is restored (in a brownout or blackout). Peri- 
odically, the memory backup batteries and 
charging system are tested for current and 
voltage under load, to identify faulty batteries 
and charging systems. 

The processors, IPB controllers, and FOXI 
modules are continually polled for status 
information. Whenever a resource being moni- 
tored changes operational state (e.g., a proces- 
sor is reset by an operator) or an abnormal 
condition is detected (e.g., a processor is fro- 
zen by a hardware error), the CHECK facility 
generates an event signature (ES), which is 
forwarded to TMDS for analysis. When condi- 
tions requiring immediate operator attention 
are detected, an audible alarm is sounded and 
an alarm message is displayed on the operator 
console. The customer has the option of per- 
mitting the CHECK facility to automatically 
notify the Tandem OSC of the alarm condition 
via a phone call placed by the system. 
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Figure 2 


Figure 3 
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Figure 2. 

RMI Operator Console 
Power and Environment 
Temperature status screen 
for a NonStop VLX 
system with a single- 
processor cabinet and 
two I/O-only cabinets. If 
any values were out of 
specification they would 
be displayed in reverse 
video. The information 

to be displayed is 
selected by marking the 
desired cabinet and 
device with any nonblank 
character and pressing 

the F7 key. 


a 
Figure 3. 

RMI Operator Console 
Power and Environment 
Power Supply status 
screen for a NonStop VLX 
system with a single- 
processor cabinet and no 
I/O-only cabinets. If any 
values were out of speci- 
fication they would be 
displayed in reverse 

video. 
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A fault-tolerant diagnos- 
tic and maintenance bus 
(DMB) links all the 
major electronic modules 
of the VLX processor 
complex together, provid- 
ing continuous monitor- 
ing and diagnostic access 
to the processor complex 


Figure 4 
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components, 
PWR/ENY, 1/O cabinet PWR/ENYV, {/O cabinet 
PWR/ENV, I/O cabinet PWR/ENY, I/O cabinet 
PWR/ENY, I/O cabinet PWR/ENY, I/O cabinet 
PWR/ENV, CPU cabinet PWR/ENV, CPU cabinet 
Figure 5 Diagnostic Access. The CHECK facility pro- 


vides diagnostic access to the VLX processors, 
FOXII modules, and power supplies via the 
same interfaces used for monitoring these 
devices. These interfaces are used to load and 
invoke tests and to access state information 
needed to accurately isolate faults. 

The interface to the power supplies can vary 
the power supplied to the processors, allowing 
the processors to be tested under marginal 
power conditions. Processor clocks can also 
be varied to test the processor logic at higher 
than normal clock rates. This allows the ser- 
vice personnel to stress test the processors to 


Power supplies 


lg detect marginal components. 
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(4) 3) 
CHECK facility components are distributed 
throughout the system. In an entry level, or 
base, system, two 68000 microprocessors and 
eight 6809 microprocessors perform the func- 
tions of the CHECK facility. A fully config- 
ured 16-processor system has eight 68000 
microprocessors and seventy 6809 micropro- 
cessors. These microprocessors reside on the 
system bus controller (SBC) boards, the power 
and environmental monitor and controller 
(PEMC) boards, the FOXIL boards, and in 
each VLX processor and power supply. (See 
Figures 4 and 5.) They continually monitor 
the state of the system, its power, and its envi- 
ronment. The major components are explained 


Power 
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Figure 5. in the following sections. 
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PEMC, a power and supply operation, and 

environment monitor periodically tests the 

Jacility (PEMF) monitors memory backup 

one or two cabinets for batteries. 
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Remote Maintenance Interface (RMI). A pair 
of RMIs form the fault-tolerant operations and 
service processor for the VLX system. One 
RMI resides on each of the two SBC boards, 
typically located in CPU cabinet 1. The two 
RMIs function as a fault-tolerant processor 
pair using checkpointing techniques similar to 
those used by the GUARDIAN 90™ operating 
system, providing for a continuously available 
maintenance and operations facility. 

Each RMI is a self-contained, 68000 
microprocessor-based module, with interfaces 
to the processors, FOXII modules, and PEMCs, 
as well as the SBC power and environment 
monitoring facility, an operator’s terminal, 
and an autodial/autoanswer, 2400-bps 
modem. 

The RMIs function as the central point of 
control and communications within the 
CHECK facility and provide operator console 
functions, the remote operations and service 
interface, and the interface to all the other 
CHECK components via two diagnostic main- 
tenance buses (DMBs). Each DMB is a high- 
speed serial communication bus over which 
the major CHECK components communicate. 

The power and environment monitoring 
facility for a CPU cabinet (typically CPU cabi- 
net 1), and up to three associated I/O cabi- 
nets, also reside on the SBC boards. 


Power and Environment Monitoring Facility 
(PEMF). The PEMF comprises the hardware 
and software that monitors and controls power 
supplies and monitors fans and cabinet tem- 
peratures. Each PEMF supports monitoring of 
two system cabinets (either CPU or I/O cabi- 
nets). The facility measures analog signals 
from power supplies, fan speed sensors, and 
cabinet temperature transducers, and sends 
digital data to the RMIs. 

The PEMF for the base system is integrated 
with the RMI on the SBC boards, typically 
located in CPU cabinet 1. 


Power and Environment Monitor and Con- 
troller (PEMC). The PEMC board (also 68000 
microprocessor-based) provides an additional 
PEMF as a system grows beyond one CPU 
cabinet. There are one or two PEMC boards in 
each additional CPU cabinet, depending on 
the number of I/O cabinets in the system. 
Each PEMC supports monitoring of up to two 
I/O or CPU cabinets. 


The Power Monitor Module (PMM). The 
PMM is a 6809 microprocessor-based board 
that monitors and controls a power supply and 
memory backup batteries. The PMM gates 
analog data onto the power monitor bus 
(PMB), varies the power supply, and tests the 
processor-memory backup batteries under 
load. In addition, it does real-time monitoring 
of peak voltage values and thresholds. One 
PMM is attached to each system power supply. 
The PMMs are controlled by the PEMF located 
on either an SBC or a PEMC board and com- 
municate via the PMB. 


Fan and Temperature Sensors. Fan sensors 
detect fan rotational speed to determine 
whether the fan is operational. Each CPU and 
I/O cabinet has four temperature sensors that 
are used to measure inlet and outlet air tem- 
perature. The analog output of these sensors is 
measured by the PEMFs on either the SBC or 
PEMC. 


Diagnostic Data Transceiver (DDT). Each 
VLX processor and FOXII module has a DDT. 
The 6809 microprocessor-based DDT allows 
the CHECK facility to monitor and control 
these devices. The DDT has a parallel interface 
to the device micro-engine used to communi- 
cate with the microcode and a serial interface 
to the DMB used to communicate with the 
RMIs. When the device is being diagnosed, the 
DDTs have full access to the state of the device 
via scan logic. 
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Figure 6. 

Scan automatically config- 
ures all state logic (e.g., 
registers A, B, and C and 
control states) into a shift 
register string shown by 
the dashed line. This 
allows a diagnostic data 
transceiver (DDT) to 
read and write state for 
initialization, problem 
analysis, and high-speed 
verification using a 
built-in self-test unit. 


Scan is a technique by which all state ele- 
ments and memory of a logic assembly can be 
read and rewritten for test and diagnostic pur- 
poses. Each VLSI gate array contains at least 
one scan string, which allows all the state ele- 
ments in the gate array to be connected not 
only as functional combinatorial logic used for 
normal computation, but also as a serial shift 
chain that allows data to be shifted in and out 
of the logic array, to initialize and observe the 
state values. (See Figure 6.) Thus, the state of 
a VLX processor can be captured when a fault 
occurs and stored for later analysis. In addi- 
tion, scan is used by the built-in self-test unit. 


Error Detection, Reporting, 
and Recovery 


The VLX processors and FOXII modules use 
highly reliable VLSI gate arrays and 256-Kbit 
dynamic RAM devices to ensure greater reli- 
ability and thus reduce the need for service. 
When a failure does occur, however, it is 
detected by an extensive set of error checkers 
and reported to on-line fault analyzers, which 
locate the cause of error. Information about 
the error, along with current state information 
and previous system event history, allow accu- 
rate determination of the failing FRU. 

Built-in retry mechanisms enable the VLX 
processor to automatically detect and recover 
from many types of errors. Using redundant 
logic and storage elements, a data access fail- 
ure can be retried from the redundant element 
while the failing element is refreshed. For 
example, the VLX processor’s control store 
contains two identical RAM banks. A misread 
word from one bank can be reread from the 
other bank and the bad location can be written 
over with the data from the second bank. The 
scratch pad registers, entry point table, page 
table cache, and data cache are protected by 
similar schemes (Brown, 1986). In addition, 
single-bit error correction and multiple-bit 
error detection in memory protect the VLX 
from transient and hard memory array errors. 
More than 60% of the processor circuitry is 
similarly protected, allowing for a high degree 
of error recovery within the processor. 

Self-repairing design techniques further 
increase availability by allowing the VLX pro- 
cessor to quickly recover from some device 
failures. The VLX is equipped with on-line 
sparing modules in the entry point table, 
scratch pad registers, data cache, and control 
store. For these, when a failure is detected and 
a retry fails, the failing device is deallocated, 
the spare device is allocated, the contents are 
revived, and the processor continues applica- 
tion processing. 
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Built-in Self Test (BIST) 


Each VLX processor has its own BIST capabil- 
ity, which provides on-site test capabilities 
previously available only at the Tandem fac- 
tory. The self-test has the following advan- 
tages over traditional diagnostics: 


® No download requirement. 

= Fast execution. 

= High coverage of logic and timing faults. 
= Isolation to the FRU level (or better). 

= Not affected by microcode revisions. 

= No disk space requirement. 


The BIST unit in the VLX processor is capa- 
ble of running over 80 Mbytes of scan-based 
verification test patterns in less than 0.7 sec- 
onds with very high fault coverage. This 
hardware-based, firmware-controlled test sys- 
tem is invoked every time a CPU is powered 
on. It can also be invoked by a TMDS com- 
mand or an automatic fault analyzer. 

The BIST is included in each VLX proces- 
sor’s DDT. It consists of a small firmware- 
controlled test processor, a pattern generator, a 
parallel scan read/write mechanism, and sig- 
nature analyzers. 

The BIST automatically generates and 
applies 2.56 million test patterns to all scan 
strings. Each pattern is loaded and then 
stepped one or more cycles to test timing sen- 
sitivity (at full speed or under a higher speed 
margin clock), and the result is then sampled 
by the test signature generator. At any point in 
the testing the signature values can be com- 
pared to known values to determine the qual- 
ity of machine operation. 


The BIST first isolates detected failures to 
an individual scan string. Then, under the 
direction of TMDS, a binary search technique 
and a special signature mode can be used to 
further isolate the fault to the failing bit or 
bits. Applying a fault analyzer to the failing 
bits allows fault isolation to the most likely 
area of failure. 

Although the 80 Mbytes of automatically 
generated test vectors provide a full verifica- 
tion test, additional test vector sequences can 
be run. Through statistical data collection 
using computer-aided design tools developed 
by Tandem, the design team identified logic 
that is difficult to test and isolate. These same 
tools can create additional test vectors that 
may be applied to the logic and give greater 
coverage for specific classes of faults. The 
high-speed parallel pattern loader is able to 
shift these patterns through the processor, and 
the results are compared against expected 
results or against expected signatures. In 
addition, a complete set of microdiagnostics is 
available to functionally verify all processor 
sections and interfaces. 


Design for Ease of Service 
and Operation 


No special service tools are required to service 
most assemblies in the VLX processor com- 
plex. Simple fasteners and connectors allow 
easy error-free removal and replacement of 
FRUs. LED indicators allow customer engi- 
neers to quickly identify and replace failed 
modules. 
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Figure 7 
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Figure 7. 


RMI Operator Console 
Main Menu Screen, The 
operator may select any 
of the available screens 
from any other. The 
operator may switch to a 
GUARDIAN 90 com- 
mand interpreter by 
using the SF1 key and 
return to the RMI main 
menu using the SF16 
key. Status information is 
always available, but to 
perform control opera- 
tions the operator must 
log on to the RMI using 
the RMI LOGON/ 
LOGOFF screen. Exten- 
sive help ts available for 
each screen. 
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Each CPU cabinet is identified with a cabi- 
net ID number (1, 2, 3, or 4). The VLX pro- 
cessor boards, FOXII modules, power supplies, 
and CHECK assemblies are capable of report- 
ing their cabinet and location within the cabi- 
net. Each assembly contains nonvolatile 
storage elements in which part number, revi- 
sion level, and tracking ID, as well as a brief 
event history, are stored. Processor, SBC, 
PEMC, and FOXII boards have three lights, 
indicating: 


# Exception/abnormal event (red). 


= Normal (green). 
# Power on (yellow). 


Processor, FOXII, and CHECK modules are 
easily replaced. Special circuits within each 
module sense removal, and the assembly is 
automatically powered off. Special color cod- 
ing and connector keying prevent installation 
of a board into the wrong slot. There are no 
interconnect cables between boards, so 
removal and insertion of boards is a simple 
one-step operation. 

All power cables are keyed to prevent errors 
during installation. Power modules slide on a 
tray and are secured with a single thumbscrew, 
as are the battery modules. Modular fan 
assemblies are used to allow quick removal 
and replacement. 

Compared to earlier systems, operating a 
VLX system has been simplified. Individual 
CPUs no longer have their own lights and 
switches. Instead, operations are controlled 
from a local operator/service terminal or from 
a remote system. A menu-driven operator 
interface, with password security, allows the 
operator to manage the VLX system from a 
single terminal. From the same terminal, all 
power and environmental measurements are 
displayed in real time. (Refer to Figures 2, 3, 
and 7.) 

In addition, a single system control panel 
secured by an operator’s key provides basic 
system operation functions. These functions 
include cold load, remote access enable or 
disable, and local RMI password checking 
enable or disable. Audible and visual alarms 
alert the operator to system-level errors. 

A fault-tolerant battery-operated clock 
automatically resets system time at cold load 
or after a power outage. The clock is fully 
integrated into the GUARDIAN 90 timekeeping 
facility so as to minimize the need to reset it. 


Automatic Fault Analysis 


The implementation of TMDS for the 
NonStop VLX system includes automatic fault 
analysis. (See Figure 8.) TMDS continuously 
collects information from the CHECK facility 
and other sources. This information is main- 
tained in an event signature log (ESLOG), that 
is continuously monitored by a process to 
determine whether failure has occurred. When 
an abnormal condition exists (i.e., one that 
may require operator intervention), TMDS 
executes a specific fault analyzer (SPECFA). 

The SPECFA examines the ESLOG entries 
and collects data from other sources to deter- 
mine whether a fault actually exists. If the 
SPECFA determines a fault exists, it attempts 
to identify the faulty FRU using the data in the 
ESLOG. The system control panel alarm noti- 
fies the operator. Optionally, if enabled by the 
customer, a telephone call is automatically 
placed to a Tandem OSC. 

Currently, most NonStop VLX processor 
faults are identified by TMDS SPECFAs. Some 
disk and magnetic tape and FOXII faults are 
also analyzed by SPECFAs. In the future, all 
components of the NonStop VLX system will 
be fully covered by fault analyzers. Remote 
event recording at the Tandem OSC will be 
used to collect and further study these analyses 
to provide continued improvement in FRU 
problem determination and isolation. 


Conclusion 


The NonStop VLX system has made signifi- 
cant advances in reducing the cost of owner- 
ship of large OLTP computer systems. The 
features that reduce its cost of ownership have 
already been proven in the field. These fea- 
tures will continue to be improved based on 
experience gained with the VLX, benefiting 
future Tandem systems even further. 
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Figure 8. 


TMDS fault-analysis 
components. Event signa- 
tures are sent to the 
TMDS $ZLOG process 
by many system compo- 
nents. The $ZMOM 
process looks at all arriv- 
ing events and determines 
if a SPECFA should be 
run. CPU FA and Cabi- 
net FA are examples of 
SPECFAs which are run 
only when required. The 
results of fault analysis 
can be viewed using the 
TMDS problem reporter, 
which is invoked using 
the TMDS DISPLAY 
command. 
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Remote Support Strategy 


emote support is an 
approach that has been 
evolving within Tandem for 
several years. This article 
traces that evolution from 
its inception in 1979 to 

the present. 

Tandem is committed to providing out- 
standing customer support, a commitment 
that requires meeting or exceeding customer 
expectations for quality support. Those expec- 
tations include greater system reliability, avail- 
ability, and serviceability. Therefore, in order 
to meet our customers’ expectations yet 
remain cost-effective, our strategy is not lim- 
ited to on-site system support but includes the 
capability for remote system support. With the 
introduction of the NonStop VLX system, 
Tandem announced the On-line Support Cen- 
ter (OSC). As part of the Tandem National 
Support Center (TNSC) in Austin, Texas, 
the OSC provides remote support for VLX 
systems. 


The Evolution of Remote Support 


DIAGLINK 

The announcement in 1979 of Tandem’s 
DIAGLINK for the NonStop 1+™ system 
marked the first stage in Tandem’s remote 
support plan. DIAGLINK, the diagnostic inter- 
face used by Tandem support personnel, was 
provided to all maintenance contract cus- 
tomers. Included was an async modem for 
remote access to the system. It was possible for 
authorized Tandem personnel to dial in to a 
customer’s system and obtain system status 
through GUARDIAN 90 utilities, execute diag- 
nostics with customer assistance, and do 
remote low-level debugging. 


Operations and Service Processor (OSP) 

In 1981, Tandem introduced the NonStop II™ 
system with its Operations and Service Proces- 
sor (OSP). The OSP replaced DIAGLINK as the 
maintenance interface for the NonStop IL sys- 
tem. The OSP, like DIAGLINK, included an 
async modem for remote access to the system. 
The OSP also incorporated new features, mak- 
ing it possible to diagnose failures and operate 
a system remotely. 

The OSP, a Z80-based maintenance proces- 
sor, is capable of sending and receiving mes- 
sages from each CPU via the Diagnostic Data 
Transceivers (DDTs). Upon receipt of these 
messages, the OSP displays internal status 
information on an OSP terminal. On the local 
system this gives the operations personnel or 
Tandem support personnel an internal view of 
the status of each CPU. 


Remote support personnel can operate the 
OSP in a passthrough mode, which means that 
the local OSP passes information through to 
the remote OSP. The advantage of this config- 
uration is that the local OSP logs messages that 
local operations personnel can monitor. They 
can view the same information that is used by 
Tandem support personnel in diagnosing hard- 
ware and software failures. 

The microdiagnostics resident on the local 
OSP also may be run remotely, and even 
downloaded from a remote OSP should they 
not be available on the local OSP. This makes 
it possible to run diagnostics remotely and 
to download special diagnostics to a CPU. 
Additional features include remote reload of 
processors, system cold load, and system oper- 
ation via the OSP. 


The TXP Version of the OSP. The next step in 
Tandem’s remote support evolution was the 
NonStop TXP™ system. The TXP system also 
used the OSP with an async modem, enhanced 
microdiagnostics, remote operations facilities, 
and remote support capabilities. 

The most important remote support feature 
introduced by the TXP processor was the use 
of scan design logic which makes the state of 
the processor accessible from the OSP at the 
time of a failure. The addition of scan design 
logic shortened the time required by the 
Tandem support person to diagnose a failure 
by providing more meaningful failure data. 

By increasing the memory size of the TXP 
version of the OSP over the NonStop II version 
it was possible to implement enhancements 
such as configuration of power on (PON) 
operation mode (i.e., local, remote, etc.) and 
remote-port password checking. 


Tandem’s Maintenance and Diagnostic 
System (TMDS) 

In 1984 Tandem introduced Tandem’s Mainte- 
nance and Diagnostic System, or TMDS 
(Troisi, 1985). TMDS is the latest support tool 
developed for Tandem, by Tandem. Unlike 
Shadow, Tandem’s first diagnostic system, 
TMDS operates on-line without requiring sig- 
nificant system resources. 


Remote Maintenance Interface (RMI) 

In July 1986 Tandem introduced their newest 
system, the NonStop VLX. The VLX system 
uses TMDS and the new remote maintenance 
interface (RMI). 

The RMI included with the VLX system 
provides significant improvements over the 
OSP and DIAGLINK. The RMI uses a synchro- 
nous protocol for communicating with the 
remote service location versus an async proto- 
col. This protocol change greatly reduces the 
chance that an unauthorized user could access 
a customer’s system. Additional system secu- 
rity is realized by the RMI’s requirement of a 
special remote access process (RAP), which is 
used in the Support Center for communicating 
with the RMI. By implementing the synchro- 
nous protocol and adding a special communi- 
cation process (RAP), we have virtually 
eliminated the risk of unauthorized users gain- 
ing access to the system via the RMI. The RMI 
also requires password authentication with 
each attempt made to communicate with the 
VLX system. The RMI, when communicating 
with the RAP, can accept data downloaded 
from the support system, e.g., microcode 
downloads directly into the RMI memory. 


Figure 1 
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Figure 1. 
The TNSC, located in 
Austin, Texas, consists 
of the NDC, the CAC, 
and the OSC. The ACT 
links the groups in the 
TNSC with the field 
support groups. 


Enhanced TMDS 

Significant enhancements were made to TMDS 
in conjunction with the VLX introduction. 
TMDS is now equipped with subsystem fault 
analyzers and an automatic dial-out feature 
that operate together, allowing the VLX system 
to detect events as they occur. These events are 
then analyzed, and based on the analysis, the 
VLX system dials out to the Support Center to 
report a possible failure. The heart of this 
capability is a rules-based expert system that 
selectively starts the fault analyzers to analyze 
events that have occurred and are logged in 
TMDS. 

There are several other features in the VLX 
system that are very important to remote sup- 
port. They include temperature monitoring, 
power monitoring, fan monitoring, a fault- 
tolerant RMI, availability of all fault informa- 
tion via the RMI, and a processor fault 
analyzer. (The previous article, “The VLX: 

A Design for Serviceability,”’ contains more 
detailed information on VLX features.) 


Tandem’s National Support Center 


Tandem has been developing the tools required 
to support systems remotely for the past seven 
years. These tools have been used to vary'ng 
degrees throughout the field. In most cases, 
they were used by the customer engineering 
and systems analyst organizations to dial in to 
a system prior to making a service call. With 
the advent of the VLX system and the TNSC, 
remote support moves into an even more 
prominent position. 

In 1986 Tandem set up the On-line Support 
Center (OSC) to use and support the existing 
tools for remote support. The OSC, part of the 
TNSC in Austin, Texas, extends the use and 
the benefit of Tandem’s remote support capa- 
bilities. The TNSC, as shown in Figure 1, is 
made up of three groups: 


= The National Dispatch Center (NDC). 
= The Customer Assistance Center (CAC). 
# The On-line Support Center (OSC). 


The NDC, the link between Tandem cus- 
tomers and the Tandem support organization, 
is responsible for accepting all support service 
requests, logging them into a central database, 
and dispatching the request to the appropriate 
support group. This link-up provides Tandem 
customers with centralized access to hardware 
and software support personnel 24 hours a 
day, 365 days a year. 

The CAC is responsible for supporting 
Tandem’s workstation products. The center 
also provides support on selected software 
products for Tandem Alliance members (Inde- 
pendent Software Vendor Support) and, most 
recently, first-call Tandem Software Support 
for several U.S. locations. 

The OSC is responsible for first-level remote 
hardware and software support for the VLX 
system. In the future, other Tandem main- 
frame products will have the capability of 
being remotely supported from the OSC. 


Tandem’s Automated Call Tracking (ACT) 
Software 

Linking these TNSC groups with the field is 
Tandem’s Automated Call Tracking (ACT) 
software. This connection provides Tandem 
customers with “on-line” first-level hardware 
and software support from a centralized loca- 
tion. The main objectives of the TNSC are to: 


= Complement the support currently provided 
by the field customer engineering and systems 
analyst organizations. 


= Reduce the time required to respond to cus- 
tomer service requests. 


= Reduce the time needed to detect and repair 
failures. 


=" Enhance customer satisfaction. 


Figure 2 illustrates a customer’s interface 
with the TNSC and the field organizations. 
The customer places a service request by 
phone or electronically (by automatic dial-out 
from their VLX system) to the TNSC. The 
request is logged into the ACT system for 
tracking purposes. The request is then directed 
to the appropriate support group, based upon 
contract coverage, severity of the request, and 
local commitments. All Tandem support 
groups have access to the latest information 
contained in ACT and can track the status of 
any call logged into the ACT system. Service 
requests are automatically escalated if they are 
not closed within the defined amount of time. 

Upon receiving a VLX service request, the 
OSC specialists dial in to the RMI to review 
the TMDS event log and evaluate the status of 
the system using TMDS and GUARDIAN 90 
utilities. The problem is diagnosed and fixed if 
possible. If the service request cannot be 
closed it is dispatched to the appropriate cus- 
tomer engineer (CE) or systems analyst (SA) 
for on-site trouble-shooting or parts replace- 
ment. When a request is handled in the OSC 
and dispatched to a CE/SA, the probable fail- 
ing field-replaceable unit (FRU) or subsystem 
is identified. This enables the support person 
responding on-site to be better informed and 
to make a quick repair. 


Figure 2 
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How On-line Support Works 


In the NonStop VLX system, significant 
enhancements were made within TMDS. Fault 
analyzers were added to various subsystems in 
TMDS to analyze events reported to TMDS. 
The fault analyzers react to events logged by 
TMDS. The event log is monitored for new 
event signatures received by TMDS. Subsystem 
fault analyzers are started automatically by 
TMDS. The fault analyzers, rules-based expert 
systems, analyze the logged events and 
attempt to determine what has occurred. After 
completing its analysis, TMDS may request to 
dial out to the OSC, or log the analysis in the 
event log (depending on the subsystem and the 
results of the fault analyzer). (See the preced- 
ing article for more detail.) 
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Electronic requests 
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Figure 2. 

Tandem customers can 
place service requests by 
voice to the NDC or 
electronically (VLX dial- 
outs) to the OSC. All 
service requests are 
logged in the ACT system 
and tracked until closure 
is reached. 


Figure 3 
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Figure 3. 

On-line support configu- 
ration. VLX systems are 
capable of making con- 
nections to the desig- 
nated OSC for reporting 
system problems. VLX 
systems can be connected 
directly to the OSC in 
Austin via the RMI and 
RAP interface. Event 
logs are maintained at 
the OSC in Austin. 
Customers outside the 
United States can inter- 
Jace with an international 
OSC and log their events 
to the local event log. 

All logged events are 
archived in Austin. 


Direct dial-in/-out 


Figure 3 illustrates the flow of events occur- 
ring between a customer system and the OSC 
in Austin. When a customer’s system encoun- 
ters an event that results in the start of a dial- 
out fault analyzer, the system dials out to the 
OSC. At the OSC the TMDS logfile is moni- 
tored by a program for incoming events. When 
a dial-out event is detected, the monitor pro- 
cess alerts the personnel in the OSC. The prob- 
lem is logged into the ACT system for tracking 
and escalation, then assigned to one of 
Tandem’s OSC specialists. 

Upon receiving notification of a dialed-out 
event, the specialists in the OSC dial in to the 
reporting system. During the dial-in session 
the OSC specialist runs TMDS to review the 
local event log and runs TMDS diagnostics if 
needed. In addition, it may be necessary to 
run GUARDIAN 90 utilities to determine the 
status of various subsystems or components. 


Benefits of the Tandem National 
Support Center 


There are several benefits that can be realized 
from the implementation of the TNSC. 


# The TNSC is a single point of contact for the 
customer when placing hardware or software 
requests. 


= All hardware and software service requests 
placed through the TNSC are logged, tracked, 
monitored, and escalated as appropriate. 


= The TNSC is staffed by Tandem profession- 
als committed to responding to service 
requests in the least amount of time and with 
the appropriate resources. 


= A high level of service is provided to cus- 
tomers without incrementally increasing their 
maintenance costs. 


= The time required to repair is reduced. 


= The cost of maintenance, which is directly 
related to the customer’s cost of ownership, is 
better controlled. 


Conclusion 


The implementation of Tandem’s National 
Support Center is a major step toward provid- 
ing additional services to our customers with- 
out incrementally increasing their maintenance 
costs—more is provided for less. For example, 
Tandem’s ability to control service costs on 
newer products is directly related to reduced 
maintenance costs. In addition to the cost 
savings, there is greater system availability as 
response time and repair time are reduced. 

Plans are under way to make full use of the 
TNSC through a gradual process of providing 
more sophisticated products, diagnostic tools, 
and support channels. 
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andem’s newest Systems 
Network Architecture (SNA) 
product, SNAX Advanced 
Program Communication 
(SNAX/APC) software, 
enhances Tandem’s network- 
ing and transaction process- 
ing capabilities. It allows applications on a 
Tandem system to participate in conversations 
as peer partners to applications on any other 
systems or devices offering similar functional 
protocols. Prior to SNAX/APC availability, 
applications were required to emulate some 
device protocol in order to communicate with 
applications in other systems. 

This article provides the following informa- 
tion about SNAX/APC: 


= Introductions to SNA logical units, 
Advanced Program-to-Program Communica- 
tions (APPC), and LU 6.2 protocol. 


= A description of the highlights and compo- 
nents of SNAX/APC. 


# A discussion of application design consider- 
ations for SNAX/APC. 


SNA Logical Units 


IBM announced SNA in 1974 to provide termi- 
nal, line, and application sharing. The primary 
objectives of SNA were to allow the sharing of 
network resources and connection of unlike 
devices. 


SNAX/APC: 
Tandem’s New SNA Software 
for Distributed Processing 


The Virtual Teleprocessing Access Method 
(VTAM), a common access method for all 
mainframe applications, was the first access 
method to support SNA. Before VTAM was 
introduced, each host or mainframe applica- 
tion owned all of its associated lines and ter- 
minals. Communication protocols were not 
capable of supporting different device types on 
the same line, and end users were required to 
have different terminals for each application 
accessed. 

SNA introduced the concept of the /ogical 
unit (LU). Described as the end user’s ‘“‘port 
into the network,” the LU is an SNA network- 
addressable unit that provides protocols for 
end users to gain access to the network and to 
the functional components of the LUs. 

End users were defined to be terminal oper- 
ators or application programs, thus the con- 
cept of LU-to-LU sessions. A logical unit type 
is defined by selecting a set of optional proto- 
col parameters that define the rules for estab- 
lishing and controlling sessions between LUs. 

LU Type 0 is an undefined protocol that 
allows implementors to select any set of avail- 
able protocol rules, as long as the two LUs are 
able to communicate with each other success- 
fully according to the rules chosen. Therefore, 
all LU types are an implementation of LU 
Type 0. 
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The very first LU types implemented by 
IBM products were for devices. LU Type 1 was 
associated with a Physical Unit (PU) Type 1, a 
relatively dumb terminal, and LU Type 2 was 
associated with a PU Type 2, a more intelli- 
gent terminal cluster controller, such as the 
3270 Display System. Most IBM VTAM appli- 
cations supported LU Type 1 and LU Type 2. 

The evolution began when support for 
devices with characteristics different from the 
original implementations were required. LU 
Type 3 was implemented to support printers 
with a different data stream format, and LU 
Type 4 was implemented so that office system 
products could transfer documents. 

IMS/VS support for the 3600 Finance Com- 
munication System was named Secondary 
Logical Unit Type P, for “programmable.” 
Not being a numbered LU type, SLUTYPEP 
was considered an implementation of LU 
Type 0. In addition to adding confusion to the 
nomenclature, it was also the first implemen- 
tation of a program-to-program protocol. 

If the LU numbering and naming scheme 
were to continue in this fashion, new LU types 
would be introduced almost as quickly as new 
device capabilities were developed. A common 
LU type that would suffice for all devices and 
possibly for all programs was needed. 

User requirements to communicate between 
two or more CICS/VS systems, two or more 
IMS/VS systems, and ultimately, between these 
two systems, led to the development of Inter- 
systems Communication (ISC) and LU Type 6, 
the development and proving ground for LU 
Type 6.2 (or LU 6.2). 

The development of LU 6.2 included the 
definition of protocol boundaries between the 
upper SNA layers and a more comprehensive 
definition of an LU. In addition to serving as 
a port into the network, LU 6.2 defines a spe- 
cific set of services, protocols, and formats for 
communication between logical processors. 


IBM has indicated that LU 6.2 is the basis 
for all future SNA communication between 
processors. There will, no doubt, be enhance- 
ments to all layers of the architecture, but the 
implications are that those changes will pro- 
vide upward compatibility for existing LU 6.2 
implementations. 


APPC 


APPC is a synchronous protocol for moving 
information between two application pro- 
grams. It can be used for transaction process- 
ing, database query support, and file transfer 
applications. As an extension to SNA, it pro- 
vides communication support for distributed 
processing. 

The term APPC is used generically to 
describe a set of services and protocols for 
communication between distributed applica- 
tions on similar and dissimilar systems. First 
introduced by IBM in 1982 and off to a seem- 
ingly slow start, it is now rapidly becoming 
the standard for intersystem communication. 
The advent of personal computers in the busi- 
ness community has highlighted the need for 
intelligent program-to-program interfaces. 

APPC encompasses LU 6.2 and PU Type 2.1 
implementations upon which the following 
architectures are based: SNA Distributed Sys- 
tems (SNADS), Distributed Data Management 
(DDM), and Advanced Peer-to-Peer Network- 
ing (APPN). APPC offers new functional 
capabilities not provided by former LU types. 

Through its synchronous-commit protocols, 
APPC is the first protocol to support distrib- 
uted processing and distributed databases 
between unlike systems. APPC is also system- 
and device-independent, making it the primary 
candidate for future product implementations. 

In addition to providing an architectural 
base for functional enhancements, APPC 
offers three distinct advantages over earlier 
LU type implementations: 


= Distributed processing among unlike 
systems. 

= Commit processing. 

= Session sharing. 
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Distributed Processing Among 

Unlike Systems 

The APPC architecture, with its unique proto- 
cols, provides the capability to develop distrib- 
uted processing applications across SNA 
networks of unlike systems. Application pro- 
grams can be developed to communicate with 
application programs independent of the pro- 
cessor type or operating systems providing the 
lower levels of support. 

APPC provides the base for the SNADS, 
DDM, and APPN architectures. SNADS 
employs APPC for the asynchronous retrieval 
and distribution of information, DDM uses it 
for accessing file records on remote systems, 
and APPN uses it to route information 
between peer nodes in a peripheral network. 


Commit Processing 

Commit processing is the first SNA implemen- 
tation of a communication protocol that pro- 
vides support for distributed processing and 
distributed databases. APPC protocols allow 
application programs to request confirmation 
of activity from the remote application pro- 
gram. The highest level of protocol provides 
for the synchronization of resources in multi- 
ple nodes. Commit processing allows a choice 
of implementations depending on the degree of 
remote commitment required. Three levels of 
confirmation are defined by the architecture: 


® None is for applications that do not require 
confirmation of remote activity and is there- 
fore the easiest to design and implement. 


® Confirm allows an application program to 
confirm with the partner application program 
that data was delivered or a function was 
performed. 


® Sync-point employs a two-phase commit 
philosophy. It ensures data integrity among 
multiple nodes by providing the protocol to 
synchronize resources at the previous sync- 
point. This implies the ability to back out 
changes to resources. 


Session Sharing 

A session is defined by SNA as the connection 
between two LUs. Sessions are expensive to 
establish and terminate. A conversation, on 
the other hand, is started and ended with effi- 
cient SNA bracket protocols. A conversation is 
conducted between two application programs 
and is, by definition, shorter than a session. 
Sessions are allocated to conversations for the 
duration of the conversation. 

APPC sessions are serially reusable 
resources, meaning they can only be used by 
one conversation at a time. The LU controls 
application program access to the session 
resource. 

A session that is serially shared by conversa- 
tions may become a resource bottleneck. At 
what point the bottleneck occurs depends on 
the volume and length of the conversations. 
APPC solves this contention problem by using 
an optional function called parallel sessions. 
Parallel sessions are more than one session 
between the same two LUs. Parallel session 
LUs allow concurrent conversations by allocat- 
ing new conversations to available sessions. 


LU 6.2 


LU 6.2 provides a group of services to end-user 
application programs. These services are gen- 
erally described in four categories: 


" Presentation services for presentation of 
data to the end user. 


« Transaction services for performing transac- 
tion processing on behalf of the end user. 

= LU services for managing the resources of 
the LU. 


= The half-session component, representing 
one half of the SNA LU-to-LU session. 


Figure 1 


LU Layers 


Lower SNA Layers 


Figure 1. 


SNA layers and protocol 
boundaries. The logical 
unit, here LU Type 6.2, 
represents the upper four 
layers of the SNA archi- 
tecture. Protocol bound- 
aries between functional 
layers and between peer 
components are imple- 
mented with a defined set 
of verbs, parameters, 


End-user 
= Protocol Boundary 


Mapped Conversation 
Protocol Boundary 


Basic Conversation 
Protocol Boundary 


Path Control 
Protocol Boundary 


Of the several functional components of LU 
6.2, two concepts are important for implemen- 
tors of applications to understand: the con- 
cepts of protocol boundaries and transaction 
services. (Refer to Figure 1 during the follow- 
ing discussion.) 


Protocol Boundaries 

The LU comprises the upper four layers of the 
SNA architecture. The two upper layers, Pre- 
sentation Services and Transaction Services, 


Protocol boundaries are defined by a set of 
verbs and parameters that represent control 
values and functions to be performed. These 
boundaries define the protocols for communi- 
cating between layers or between peer compo- 
nents of the architecture. Protocol boundaries 
also exist between functional components 
within the SNA layers that represent sublayers. 

Layer protocol boundaries occur between 
layers, and peer protocol boundaries occur 
between components of the same layer. An 
example of a layer protocol boundary is the 
Path Control Protocol Boundary between the 
Transmission Control layer and the Path Con- 
trol layer. It defines a specific protocol for 
communicating with Path Control. 

The LU 6.2 architecture defines the Mapped 
Conversation Protocol Boundary and the 
Basic Conversation Protocol Boundary, which 
represent logically different sublayers within 
presentation services. There is also the End- 
user Protocol Boundary or application pro- 
gram interface, which may be implemented 
differently in various LU 6.2 products. 

An example of a peer protocol boundary is 
two transaction programs communicating 
with each other through the Mapped Conver- 
sation Protocol Boundary. (Note that the layer 
protocol boundary and the peer protocol 
boundary would be the same for peer compo- 
nents in the network.) 


Transaction Services 

Presentation services and transaction services 
functions have been significantly enhanced in 
LU 6.2. Components within these layers con- 


and proweotss provide data handling and end-user services vert requests from one layer format to the 
for the LU. The two lower layers of the LU adjacent layer. One example in presentation 
represent the LU Half Session, which is services is the mapper, which converts mapped 
responsible for Data Flow Control and Trans- conversation verbs to basic conversation verbs. 
mission Control, and is essentially the same Conceptually, transaction services are an 
for all LU types. extension of LU functions, performing work 
A major function of the LU is to convert for users that would otherwise have to be per- 
between the End-user Protocol Boundary and formed by user applications. Transaction ser- 
the lower layers of the architecture at the Path vices are performed by service transaction 
Control Protocol Boundary. programs (Service TPs). For example, if a user 
application required movement of a data file, 
the user program would normally have to read 
each record of the file and send it to the 
receiving application. With distribution ser- 
vices implemented, the user application can 
request movement of the file, which is then 
performed by the Service TP. 
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An LU 6.2 may also exist in an intermediate 
node where service functions are performed 
without end-user participation. A good exam- 
ple is a distribution system in which informa- 
tion is being transferred from node A to 
node C through node B. The LU at node B 
performs the intermediate storage and 
retrieval of the information, and no user 
application is required. 


Transaction Programs 

LU 6.2 defines two types of transaction pro- 
grams (TPs): application TPs and Service TPs. 
Application TPs are the end-user business 
application programs, generally written by 
users, Service TPs are defined within the LU 
to provide services to the end user. 

Service TPs are intended by architectural 
definition to be provided by the vendor. They 
provide control operator functions, distribu- 
tion services, and synchronization services. 
Application TPs are intended to use the 
Mapped Conversation Protocol Boundary, and 
Service TPs to use the Basic Conversation 
Protocol Boundary. (In the rest of this article, 
the term 7P represents application TP unless it 
is otherwise identified.) 

TPs communicate with each other over con- 
versations using LU 6.2 verbs and protocols. 
All application-to-application conversations 
are half duplex, in which one TP is in send 
state and the other is in receive state. The pro- 
tocol specifies proper use of the verbs in each 
State. 


LU 6.2 Verbs 

Verbs and their associated parameters are used 
to implement the LU 6.2 protocol boundaries. 
LU 6.2 defines a base set of verbs for basic and 
mapped conversations, and two additional 
groups of verbs that add functionality. It also 
defines many option sets that are implemented 
through these optional verbs or through addi- 
tional parameters on the base set. Some option 
sets are independent, and others have prerequi- 
site option sets. Three of the more significant 
options available are support for data map- 
ping, control operator verbs, and sync-level 
commit processing. 


Basic Conversation Verbs. Every 6.2 product 
is “required” to implement the base set of 
basic conversation verbs. The base set is the 
minimum required to initiate, carry on, and 
terminate a conversation between two applica- 
tion programs. SNAX/APC supports the base 
set of basic conversation verbs. 


Mapped Conversation Verbs. Mapped conver- 
sation verbs provide a higher-level application 
program interface that frees the application 
programmer from the rigors of formatting the 
user data into the generalized data stream 
(GDS) and, of course, unformatting the data 
on the receiving end. 

GDS is a standard data stream format that 
allows unlike systems to send and receive rec- 
ognizable data records. It includes length 
fields, data-type variables, and control infor- 
mation for logically blocking and unblocking 
records. GDS variables for mapped conversa- 
tions are created by the mapped support 
within the LU. TPs written for basic conversa- 
tions are responsible for appending and inter- 
preting the GDS variables. 

A second optional function called data 
mapping should not be confused with mapped 
conversations. Data mapping support allows 
TPs to request the mapping services of the LU, 
including sending map names to partners. The 
map names are used to retrieve stored maps 
for mapping the data into the desired format. 
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Figure 2 


Figure 2. 


SNAX LU support. 
SNAX/APC is similar to 
the SNA3270 interface, 
SNAX/HLS, and 
EXCHANGE/SNA in 
that it shelters applica- 
tion programmers from 
the complexities of SNA 
and the SNALU 
interface. 
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Mapped conversation verbs are generally the 
same format as the base conversation verbs 
with the exception that they are prefixed by the 
characters MC_ for mapped conversation, and 
some associated parameters are different. 


Control Operator Verbs. Control Operator 
Verbs are used by programs to control func- 
tions of the LU. Such functions include acti- 
vating and monitoring sessions, changing the 
number of sessions, and coordinating with the 
partner LU. The majority of operator verbs 
deal with the operation of parallel sessions. 


Type-independent Verbs. Currently four verbs 
are defined as type independent, meaning they 
can be used for either basic or mapped conver- 
sations. All four verbs are associated with 
option set implementations. The type- 
independent verbs are BACKOUT, GET_TYPE, 
SYNCPT, and WAIT. 


SNAX/APC Highlights and 
Components 


SNAX/APC extends Tandem’s family of SNA 
products to include support for APPC. It 
allows Tandem applications to communicate 
with applications in another system that sup- 
ports LU 6.2. SNAX/APC supports basic con- 
versations over single SNA sessions. It is a 
system of components that provides a means 
of configuring, operating, and tracing the 
environment, in addition to converting from 
the high-level application program interface to 
SNA protocols. SNAX/APC was designed to 
use the facilities of Tandem’s PATHWAY trans- 
action processing system. 


SNAX/APC Highlights 


Extended Distributed Processing. SNAX/APC 
enables users to implement distributed pro- 
cessing applications that include other logical 
processors in an SNA network. The commit 
protocols of LU 6.2 allow applications to con- 
firm processing in other nodes. 


PATHWAY Integration. The APC communica- 
tions process is implemented as a PATH WAY 
server, and SNAX/APC application TPs can be 
written as PATHWAY requesters or servers. The 
APC dispatcher uses the process-creation func- 
tion of PATHMON to create new TP servers. 
TPs may also be run outside the PATHWAY 
environment. 


Application Program Interface (API). The 
SNAX/APC End-user Protocol Boundary is 
the high-level API that acts as an interface 
between user-written TPs and the APC server. 
It protects the application programmer from 
the complexities of the lower levels of the SNA 
architecture. 


Languages. Application TP servers can be 
written in any language supported by Tandem. 
Requester TPs are written in SCREEN COBOL. 


Multiple LUs. One APC server can be config- 
ured to support up to 32 LUs, allowing up to 
32 concurrent conversations. Additional APC 
servers can be started for more LUs. 


Configuration Database. Database files con- 
tain a predefined list of local transaction pro- 
grams and their allowed associations with 
partner LUs. 


Trace File. An on-line trace can be activated 
to record all interprocess messages sent and 
received by SNAX/APC. 
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Log File. SNAX/APC also writes an activity Figure 3 
log, containing initialization statistics and 
configuration errors, to a user-defined exter- 
nal file. 


SNAX/APC System Components 
The SNAX/APC system is composed of: 


= A multithreaded server process (written in 
TAL™, Tandem’s Transaction Application 
Language) that implements LU 6.2 services. 
# An application dispatcher (written in 
SCREEN COBOL) that initiates TP servers. 


= A configurator interface (written in 
SCREEN COBOL) that defines the authorized 
configuration. 


= A trace facility for problem determination. 


Figure 3 illustrates the structure and compo- 


nents of the SNAX/APC system; refer to it ees a APC 


during the following discussion. configurator dispatcher 
The APC server provides a program inter- oe ae : 
face for user applications. It uses GUARDIAN 90 : : Requester 


File System calls to interface to SNAX. Each 
server can be configured for up to 32 LUs, and 
multiple servers can coexist in a single SNAX/ 
APC environment. The APC server links local 
TPs with remote LUs through definitions in 
the configuration database. It enforces the Figure 4 
correct application TP protocols by parsing 
requests and maintaining conversation status. 
Multiple APC servers can be started, depend- 
ing on the number of LUs or other application 
requirements. For example, different network 
configurations, destinations, or applications 
may use different APC servers. 


of a unit of work (UOW). Application TPs Figure 3. Figure 4. 

communicate with the APC server by sending SNA X/APC system dispatcher to invoke Format of interprocess 

i i ; P structure, SNAX/APC application server pro- communication messages 

ee ag, ape ee ‘ ee is a system composed of cesses, and the APC (IPCs). The IPCs passed 

containing = cont instances, . an operator process for server, which provides a between the TP and 

may contain multiple UOWs (see Figure 4), defining the network high-level API for trans- SNAX/APC contain an 

reducing the cost of interprocess configuration, a action programs. identifying header and 

communication. units of work containing 
Two types of UOW are defined for inter- the LU 6.2 verb, parame- 


. . ter, and return codes. 
process communication: 

# Service UOWs establish contact between TPs 
and the APC server. Each IPC can contain 
only one service UOW. 


= Conversation UOWSs carry LU 6.2 conversation- 


verb requests and replies between the TP and 
the APC server. 
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Figure 5 


Partner LUs 


Sg 
Figure 5. 
SNAX/APC configura- 
tion objects and linkage. 
The SNAX/APC config- 
uration process includes 
definition and linkage of 
the local objects and the 
partner LU and mode. 
The mode identifies the 
BIND image for the SNA 
session. 


The APC dispatcher invokes local TPs when 
requested to do so by the APC server, as the 
result of an ATTACH request from a remote 
TP. When the APC server processes a remote 
request, it first checks to see if the TP is 
active, and if not, the APC dispatcher creates 
the local TP through the PATHWAY monitor’s 
(PATHMON’s) process creation facility. 

The APC configurator is provided to config- 
ure the SNAX/APC environment. It presents 
menus for defining SNAX/APC objects and 
linking the objects into the desired configura- 
tion. The results are stored in configuration 
database files. 

The APC configurator provides ENABLE 
menus to define the local LU, the partner LU, 
the mode for the partner LU, and the local 
TPs. Once these objects have been defined, the 
APC configurator provides additional menus 
to link the TPs to a local LU, the local LU to a 
partner LU, and the partner LU to a mode 
entry, thus completing the configuration pro- 
cess. Figure 5 represents the configured 
objects and the required linkage. The partner 
TP is not defined in the configuration; it is 
supplied by the local TP at execution time. 


The trace facility consists of an internal 
trace generator and the trace formatter. 

The trace generator captures information 
flows between the TP and the APC server and 
between the APC server and SNAX. The trace 
formatter formats and prints the trace data 
according to user-specified parameters. 

In addition to these system components, the 
SNAX/APC environment includes the user- 
written application TPs, which supply the 
business-function logic. These can be written 
in any language and can be implemented as 
PATHWAY servers or requesters or as indepen- 
dent processes. 


Application Design Considerations 


Many design alternatives exist for applications 
that are to use SNAX/APC. It is not practical 
to address all the design considerations in this 
article, but the following discussion should 
provide a general understanding of the alterna- 
tives. While detailed knowledge of SNA is not 
required for designing APPC applications, 
application designers should be familiar with 
basic SNA concepts and facilities. 


Use of Proper Terminology 

As with most new protocols, APPC has gener- 
ated its own new terminology. Some of the 
terms may be confused with other similar 
ones, and some are confusing even within the 
context of APPC. The glossary on the opposite 
page contains definitions of commonly con- 
fused LU 6.2 terms and their relationship to 
each other. 

Each term describing a TP has a meaning 
relative to its antonym, but each pair of terms 
is independent of the other pairs. For example, 
the source TP may be on the primary or sec- 
ondary LU, may be in send or receive state, 
and may be local or remote, depending on the 
speaker’s point of reference. 


Potential Environments for SNAX/APC 
SNAX/APC extends Tandem’s already strong 
SNA capabilities by providing a base on which 
to build applications involving different types 
of distributed processors. It enhances the role 
of the Tandem system as a gateway, as a host 
supporting a wide variety of devices and per- 
sonal computers, and as an interface for appli- 
cations communicating with applications in 
other Tandem networks. 
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APPC Glossary 


Session and Conversation 


An SNA session is established between two LUs. An LU 
6.2 conversation is conducted between two transaction 
programs (TPs) over a session. SNA bracket protocols 
are used to delineate conversations within a session. The 
ALLOCATE verb requests allocation of a conversation 
to a session. 


Primary and Secondary 


Primary and secondary are SNA terms for describing the 
LU’s role when the session is established. The primary 
LU sends the BIND request that causes the session to be 
established, and the secondary LU receives the BIND 
request. Rules defined in the BIND request determine 
which of these is the first speaker in the exchange of 
information. (TP design is independent of this LU 
status.) 


Allocate and Attach 


A TP issues an ALLOCATE verb to allocate a conversa- 
tion to a session and provide the local LU with the name 
of the partner TP to be attached. The ALLOCATE 
request causes the local LU to generate an SNA 
ATTACH Function Management Header (FMH-S5) and 
send it to the partner LU to attach the partner TP. 


Source and Target 


These are adjectives describing LU 6.2 TPs. The source 
TP is the program that initiates a conversation by send- 
ing an ALLOCATE verb. The target 7P is named in the 
ALLOCATE request as the conversation partner. 


Send and Receive States 


The source TP is in send state when a conversation is 
started, and the target TP is in receive state. LU 6.2 
conversations are half duplex, meaning that only one TP 
is in send state at a time. Protocol dictates which verbs 
can be issued in each state and which verbs result in state 
changes. 

TPs can be in states other than send or receive. Other 
program states define pending actions, such as confirma- 
tion and deallocation, or reset, which indicates that no 
conversation is allocated. 


Local and Remote 


Local and remote are used to describe geographic points 
of reference. The /ocal TP is here; the remote TP is there. 
For example, when the Tandem environment is the focus 
of the discussion, the local LU and local TP are in the 
Tandem system and the remote LU and TP are in the 
other system. If the discussion is centered on the IBM 
system, the Tandem system becomes the remote one. 
Partner is also commonly used to mean the other TP 

or LU. 
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Gateway to IBM Host Applications. Using 
SNAX/APC, Tandem systems can provide a 
gateway to IBM mainframe applications in an 
LU 6.2 environment. The added functionality 
of commit processing makes it possible to 
confirm receipt of data on either node. In 
some instances, SNAX/APC could help to 
reduce the number of sessions required 
between nodes by sharing the sessions, to the 
extent allowed by performance requirements. 


Workstations in a Tandem Network. SNAX/ 
APC applications can communicate with 
mainframe computers, personal computers, 
and other workstations implementing APPC. 
A program called APPC/PC is available for 
personal computers. The IBM System/36 and 
System/38 have APPC support. Other vendors 
have announced or intend to support APPC, 
and new devices will be supported when they 
are introduced. 


Other Networks. SNAX/APC can be very 
effective at connecting independent Tandem 
systems or networks across SNA links. It may 
be useful for connections with other networks 
as well. For example, an organization offering 
networking services may wish to provide appli- 
cations to other Tandem customers through 
program-to-program communication. For this 
type of connection, APPC protocols remove 
some of the burden of application design and 
implementation. In some cases it may offer an 
SNA alternative to existing protocols. 


Communication Between 

Transaction Programs 

Program-to-program communication imposes 
some of the burden of protocol management 
on the application program designers. The 
protocols are half duplex, meaning that only 
one TP can send data at a time and the other 
must be in receive mode. The protocol allows 
exceptions to this rule for control information. 
Each TP’s activity must be carefully coordi- 
nated with that of the conversation partner. 
The source program is put in send state after 
allocation, and the target program is put in 
receive state. 

TPs can be involved in more than one con- 
versation at a time (e.g., a business transac- 
tion may require conversations with multiple 
partners concurrently). TPs can also be writ- 
ten as multithreaded programs capable of han- 
dling unrelated conversations concurrently. 

One of the major differences between 
mapped and basic conversations is the creation 
and interpretation of the GDS. TPs written for 
basic conversations are responsible for han- 
dling the GDS variables. 

Some implementations of APPC support 
only mapped verbs and, thus, only mapped 
conversations. Other implementations allow 
applications to use either basic or mapped 
verbs. SNAX/APC does not support mapped 
conversation verbs, but it does provide the 
capability to communicate with remote TPs 
that use mapped verbs. This capability 
requires the application TP to create and rec- 
ognize the additional GDS variables that may 
flow in mapped conversations and to respond 
correctly. Supporting communication with 
remote TPs that use mapped verbs provides an 
interim solution until SNAX/APC support for 
mapped conversation verbs is available. 


Use of SNAX/APC with PATHWAY 
PATHWAY is Tandem’s transaction processing 
system. As mentioned earlier, the APC server 
is a PATHWAY server; TPs can be PATH WAY 
servers or SCREEN COBOL requesters; and the 
SNAX/APC system is configured with 
ENABLE screens. PATHWAY is not an absolute 
requirement for SNAX/APC; however, imple- 
mentation without PATHWAY would involve a 
great deal more effort as configurator and 
dispatcher functions would not be available. 

The APC dispatcher uses PATHMON’s pro- 
cess creation mechanism as one way to create 
new TP server processes. TP servers are sensi- 
tive to conversation context, so the entire con- 
versation must be completed within a single 
execution of a TP. The TP should not reply to 
the APC dispatcher until communication with 
SNAX/APC is complete. 

SCREEN COBOL TPs provide a way to con- 
nect devices supported by PATHWAY to 
remote APPC applications. SCREEN COBOL is 
viable for many application programs, and it 
offers the advantages of PATH WAY’s server 
management for database access. 


Starting Conversations 
A conversation can be started in several ways. 
TPs can become a partner in a conversation 
either by issuing the ALLOCATE verb to attach 
a remote TP or by being attached by a remote 
TP. In either case, the program must be active 
and must notify SNAX/APC of its presence by 
sending a program initialization parameter 
(PIP) request. The PIP request is a service 
UOW indicating the program’s start-up inten- 
tions through the parameter specifications. 
TPs can be started locally by CI or TACL 
commands or by another process. TPs started 
in this manner can either allocate a conversa- 
tion or wait to be attached by a remote TP. 
TPs can also be started as the result of an 
ATTACH request from a remote TP. When the 
attach is received for a local TP that is not 
active at the time, SNAX/APC directs the APC 
dispatcher to create the TP. (Note that SCREEN 
COBOL TPs cannot be started through the 
APC dispatcher.) 


Performance Considerations 

The most significant performance variable 
users are likely to encounter when designing 
SNAX/APC applications is contention for the 
SNA session resource. APPC allows conversa- 
tions to share a session as a serially reusable 
resource. To guarantee availability of a session 
for each conversation, one session must exist 
for each potential conversation. Since sessions 
are longer than conversations, it is possible to 
allocate many short conversations to a session 
serially without significantly affecting per- 
formance. The duration of conversations obvi- 
ously affects the availability of the session. 

When parallel sessions are used, available 
sessions can be selected by the LU dynami- 
cally, thus reducing the contention problem. 
SNAX/APC does 
not currently sup- 
port parallel ses- 
sions; however, it 
does allow multiple 
single sessions to 
exist concurrently. 
Performance can be 
improved with this 
capability. Since there is no dynamic selection, 
application designers must determine which 
conversations are to use which sessions. 

The application program interface allows 
multiple UOWs to be sent in the same inter- 
process message. For example, a single 
WRITEREAD statement can send three verbs 
at a time to the APC server to allocate a con- 
versation, send data, and deallocate (end) the 
conversation. This capability significantly 
reduces the interprocess communication over- 
head for transaction processing environments. 


he application program 

interface significantly 
reduces the interprocess 
communication. 
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Logical and physical data record sizes are 
important performance variables. The ratio of 
physical and logical record sizes determines 
the number of interactions required to transfer 
logical records between processes. In SNAX/ 
APC the physical record sizes affect the buffer 
requirements for the APC server. Each TP can 
potentially use two maximum-size buffers. 
Users should attempt to configure their sys- 
tems to avoid use of extended memory 
segments. 

Physical record sizes need not be the same 
for both TPs in a conversation. The access 
method and LUs segment and chain the physi- 
cal records into logical records. Performance 
characteristics of each system may dictate 
different buffering requirements for their 
respective TPs. 


Conversation Verbs Supported by 
SNAX/APC 
The following verbs are supported by the cur- 
rent release of SNAX/APC. Additional levels 
of support (option sets) are implemented by 
adding new parameter variables, so all param- 
eters of a verb are not automatically included. 
A review of the basic verbs and their functions 
should convey the type of logic required in an 
application TP. Refer to the SNAX/APC Pro- 
grammming and Operations Guide for the 
format of the verbs and parameters. 
ALLOCATE indicates a request to initiate a 
conversation. The following parameters are 
supported: 


=" SYNC_LEVEL specifies the sync level of 
the conversation. None or confirm can be 
specified. 


= LUNAME (other) specifies the name of the 
partner LU. 


=" MODENAME specifies the name of a set of 
LU session parameters. 


= TPNAME specifies the name of the partner 
TP that is to be attached. 


CONFIRM indicates a request for the part- 
ner TP to confirm one or more events, such as 
the receipt of data. , 

CONFIRMED is the response from the 
partner TP to a CONFIRM request or a 
DEALLOCATE CONFIRM request. 

DEALLOCATE is a request to deallocate 
(terminate) a conversation. The TYPE parame- 
ter can have one of four values: 


= SYNC_LEVEL flushes the output buffer and 
requests the partner TP to confirm at the sync 
level agreed upon. 

= FLUSH flushes the output buffer and tells 
the partner TP to deallocate. 


« ABEND_PROGRAM tells the partner TP to 
deallocate and ignores the transmission status 
and data. This is an abnormal termination. 


= LOCAL requests the local LU to deallocate 
the local resources. This is issued locally after 
receipt of one of the above types of deallocate 
request from the partner TP. 


GET_ATTRIBUTES allows a TP to retrieve 
the partner LU name, mode name, and conver- 
sation sync level of the partner LU. 

RECEIVE_AND_WAIT puts the sending TP 
in receive state to receive data and control 
information. TPs perform receive-and-wait 
loops until all data is received and then 
respond to control information according to 
conversation protocol rules. A WHAT_ 
RECEIVED indicator tells the TP whether the 
LU has received data or control information. 

REQUEST_TO_SEND allows a TP in receive 
state to notify the partner TP that the local TP 
has data to send. The partner TP has the pre- 
rogative of when to turn the conversation 
around. 

SEND_DATA sends data to the partner TP. 

SEND_ERROR notifies the partner TP that 
a problem has been detected in the data or 
application logic. 
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Conclusion 


SNAX/APC takes full advantage of SNAX and 
the PATHWAY transaction processing system. 
It provides a high-level application program 
interface that uses standard GUARDIAN 90 
File System calis and employs an efficient 
unit-of-work concept. Applications using 
SNAX/APC can be written in any language 
supported by Tandem. 

SNAX/APC supports LU 6.2 basic conversa- 
tions over single-session LUs, meaning that it 
can support only one session, and therefore 
one conversation, at a time on each LU. 
SNAX/APC does, however, support up to 32 
LUs per APC server. This unique implementa- 
tion allows multiple concurrent conversations 
with CICS/VS. 

The next release of APC will provide pri- 
mary LU support, allowing APC to act as the 
primary to secondary LUs such as the PC. 

SNAX/APC’s internal structure is designed 
according to the JBM Formats and Protocols 
Manual for LU 6.2 and, thus, provides a base 
for additional option-set enhancements. 

Application-program design for APPC 
requires a great deal of coordination between 
the designers of application programs, unlike 
former protocols in which the remote object is 
a relatively inflexible device. 

The introduction of SNAX/APC enhances 
Tandem’s networking and transaction process- 
ing capabilities. It allows Tandem systems to 
participate as peers to any systems offering 
similar APPC capabilities. Finally, it allows 
Tandem systems to become intermediate nodes 
for distributed systems or host nodes for 
devices implementing LU 6.2. 
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Enhancements to PS MAIL 


el 
he PS MAIL™ electronic mail 
systems let correspondents 
send messages through a 
Tandem network to other 

PS MAIL correspondents. 
Tandem employees rely on it 
for their corporate commun- 
ication, as do many Tandem customers. 

In the B40 software release, PS MAIL was 
enhanced in response to user requests, includ- 
ing the results of a user survey. Also, PS MAIL 
can now access documents sent by Tandem’s 
new WORDLINK™ document exchange facility. 
WORDLINK allows users to transfer docu- 
ments between stand-alone word processors or 
word processing programs via the Tandem 
system. Finally, PS MAIL now supports 
national languages, allowing Tandem’s inter- 
national customers to have multilingual mail 
interfaces on a single system. 


The next four sections of this article present 
the following: 


= An overview of PS MAIL. This section 
describes the PS MAIL user interfaces and the 
TRANSFER™ information delivery system. It 
uses some terms specific to the product; the 
glossary, at the end of the article, defines 
them. 


= New features in PS MAIL. This section, 
intended for all users of PS MAIL, describes 
new functions and enhancements to existing 
ones. 


= WORDLINK. The beginning of this section, 
of interest to PS MAIL contacts and analysts, 
describes WORDLINK and how documents are 
stored and retrieved within TRANSFER. The 
end of the section, useful to all users receiving 
WORDLINK documents, describes enhance- 
ments to PS MAIL functions for handling 
these messages. 


= National language support. This section 

is intended for readers interested in 
TRANSFER’s approach to national language 
support. 


Refer to the glossary for definitions of 
PS MAIL and TRANSFER terms used in the 
discussion. Refer to the latest versions of the 
appropriate PS MAIL manuals, listed at the 
end of this article, for complete descriptions 
of the new features and their use. 
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An Overview of PS MAIL 


PS MAIL allows users to create, send, receive, 
and store messages. A message can contain 
many kinds of data, such as a text file, a word 
processor document, a PC text or object file, 
or facsimile data.! Messages received are 
automatically stored in an electronic folder 
called the INBOX. From the INBOX, they can 
be sent to other correspondents, filed into 
other folders, output to a printer or disk file, 
or deleted. 

A message is composed of several parts: 


# The envelope, containing the address and 
subject of the message. 


= The text of the message. 


= Optionally, attachments, such as other mes- 
sages or files. 


A message can be sent to one or more recip- 
ients. A simple way to specify many recipients 
is to use a distribution list containing corre- 
spondent names and/or the names of other 
distribution lists. 


PS MAIL User Interfaces 
There are three PS MAIL user interfaces: 


=" PS MAIL for TTY terminals is a command- 
driven, line-oriented interface. It is used on 
any terminal, including teletype (TTY) termi- 
nals, connected to a Tandem system. 


=" PS MAIL for 6530 terminals is a menu- 
driven, screen-oriented interface used on any 
Tandem terminal or workstation. 


=" PS MAIL for 3270 terminals is used on IBM 
3270 terminals (or those that emulate the 
3270). It is virtually identical in function to 
PS MAIL for 6530 terminals. One visible dif- 
ference is that the two versions use different 
function keys for command functions because 
the layouts of their keyboards differ. 


In this article, for simplicity, the name 
PS MAIL 6530 indicates both PS MAIL for 
6530 terminals and PS MAIL for 3270 termi- 
nals. PS MAIL TTY indicates PS MAIL for 
TTY terminals. 


‘In the context of this article, PC refers to Tandem PCs, IBM PCs, or IBM- 
compatible PCs. PS MAIL requires Tandem’s PC LINK software to transfer 
files between the Tandem system and a PC. 


TRANSFER and PS MAIL 

TRANSFER is an information delivery system 
that supports communications between peo- 
ple, input/output devices, and processes. The 
PS MAIL products are requester programs that 
provide the interface between correspondents 
and TRANSFER. Other products mentioned in 
this article that are used with TRANSFER are 
FAXLINK™, which allows correspondents to 
transfer documents to and from facsimile 
devices, and WORDLINK, which allows cor- 
respondents to transfer documents created 
with word processing devices or programs via 
the Tandem system. 


New PS MAIL Features 


The following are PS MAIL’s major new 
features: 


= The PRINT function has been split into three 
parts, each having specific capabilities, giving 
users greater control of their output. 

= More defaults in the correspondent profile 
(such as the default printer location and 
extended editor) can be changed by users. 

= Users can copy any distribution list on their 
node to a new or existing distribution list 
belonging to them. 

= Adding attachments to the workspace has 
been enhanced. 


= Each PS MAIL user interface has additional 
enhancements. 
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New Method for Output of Messages 
The PRINT function has been split into three 
separate output functions: 


=" COPY is used to copy messages to a 
GUARDIAN 90 or PC file. 


= PRINT is used to output messages to a 
printer or facsimile machine. 


=" FORMAT is used to output messages to a 
printer under the control of a text formatter. 


Also, multiple messages can now be copied or 
printed in a single job. 


COPY. COPY copies messages to a 
GUARDIAN 90 or PC file specified by the 
user. Descriptions of the COPY options follow. 

MSGONLY (MO) copies just the message, 
not its attachments. ALL, signifying all of the 
attachments, is the default. 

NOHEADER tells PS MAIL to copy the mes- 
sage but not the envelope (header) of the mes- 
sage. HEADER is the default. This option is 
useful for messages that will be formatted 
later. 

PURGE automatically purges the contents of 
the file (if it exists) before copying the mes- 
sage. This option can be used when copying 
messages to GUARDIAN 90 files and must be 
used when copying messages to existing PC 
files. 

TRANSLATE, followed by a language name, 
is used by PC users to identify the character 
set of the GUARDIAN 90 file so that any non- 
ASCII national characters in the file can be 
translated to their equivalent codes on the PC. 
The language can be any of the following: 


DANSK NORSK 
DEUTSCH SVENSK 
ESPANOL UK 
FRANCAIS USASCII 
NONE 


COPY also has options specifically for han- 
dling WORDLINK documents. These options 
and their effects on WORDLINK documents 
are described in the WORDLINK section of 
this article. 


PRINT. PRINT prints messages to a printer or 
facsimile machine. A printer can be given as a 
parameter; if it is not, the message or messages 
are printed on the default printer specified in 
the correspondent’s profile. Descriptions of 
the PRINT options follow. (The FAXLINK 
options have not changed and are not listed 
here.) 

MSGONLY (MO) and NOHEADER options 
are the same as for COPY. 

PAGE is used when a range of messages is 
specified for printing from PS MAIL TTY or 
when several messages are selected for printing 
from PS MAIL 6530. (Message ranges in 
PS MAIL TTY are discussed later.) The PAGE 
option forces each message to be printed on a 
separate page. PAGE is the default; NOPAGE 
causes the messages to be printed with no page 
separation between them. 


FORMAT. FORMAT is used to print messages 
to a printer under the control of a text format- 
ter. A printer can be given as a parameter; if it 
is not, the message or messages are printed on 
the default printer specified in the correspon- 
dent’s profile. The same is true for the text 
formatter used. Descriptions of the FORMAT 
options follow. 

MSGONLY (MO) and NOHEADER are the 
same as for COPY and PRINT. 

TFORM and TGAL override the correspon- 
dent’s default formatter. (TFORM is the pro- 
gram name for PS TEXT FORMAT™, a 
command-oriented text formatter.) 


Printing Multiple Messages in One Job. 

When multiple messages are selected in 

PS MAIL 6530, or selected as a range in 

PS MAIL TTY (e.g., PRINT 1/3), they are now 
output in one job. This means the output will 
have one banner page followed by all the 
printed messages instead of one banner page 
for each message. In PS MAIL TTY, messages 
selected as a list (e.g., PRINT | 2 3) are output 
as multiple jobs. 


Customizing the Profile 

More items in a correspondent’s profile can 
now be altered by the correspondent instead of 
the PS MAIL contact. These are: 


® The default formatter, used when the FOR- 
MAT command is used and a formatter is not 
specified. 

= The GUARDIAN 90 user ID and password, 
used on behalf of the correspondent to start 
programs and to create files. 


= The correspondent’s password, used to log 
on to PS MAIL. 


= The default printer, used when no printer or 
facsimile device is specified for the output of 

messages or when no facsimile device is speci- 
fied for adding attachments to the workspace. 


= The default system, volume, and subvolume, 
used on behalf of the correspondent to fully 
qualify file names. 


« The default extended editor, TEDIT, EDIT, or 
T-TEXT, used when editing messages or 
attachments. (TEDIT is the program name for 
PS TEXT EDIT”, a full-screen text editor.) 


In PS MAIL 6530, these settings can be 
changed on the new PROFILE screen, accessed 
by pressing F14.? In PS MAIL TTY, they can 
be changed with the new commands, 
ALTERFORMATTER, ALTERGUARDIANID, 
ALTERPASSWORD, ALTERPRINTER, 
ALTERSYSTEM, ALTERVOLUME, and 
ALTERXEDIT. 

Display settings in PS MAIL TTY, such as 
whether confirmation messages are displayed 
or explanations are included with prompts, 
can be changed with the new command 
ALTERDISPLAY. Note that the ALTER- 
DISPLAY, ALTERGUARDIANID, and 
ALTERPASSWORD commands replace the 
former PROFILE command. 


Copying Distribution Lists 

Correspondents can now copy any distribution 
list on their local node to a new or existing 
distribution list belonging to them. They can 
do this in PS MAIL TTY with a new com- 
mand, COPYDISTRIBUTION, and in 


?In this article, all function keys mentioned are for PS MAIL for 6530 termi- 
nals. For the corresponding keys for PS MAIL for 3270 terminals, see the 
PS MAIL Users’ Guide and Reference Manual for 3270 Terminals. 


PS MAIL 6530 with the new MERGE key (F8). 
Duplicate correspondents are automatically 
removed. 


Adding Attachments 

Adding attachments to the workspace has 
been enhanced. The enhancements give 
increased functionality to PS MAIL TTY and 
PS MAIL 6530, and provide extra features for 
PC and WORDLINK users. (The WORDLINK 
features are described in the WORDLINK 
section.) 


Automatic Workspace Creation from 

PS MAIL TTY. A workspace no longer must be 
created with the CREATEMAIL command 
before an attachment can be added. The 


ADDATTACHMENT 

command now auto- 

matically creates a C Orr espondents can now 
workspace of type . . . 
ORIGINAL AEG copy any distribution 


workspace is empty. 
This is useful for 
storing GUARDIAN 90 or PC files in PS MAIL 
folders with the COPYWORKSPACE com- 
mand. For example, the two commands 


ADDATTACHMENT PC:records7 
COPYWORKSPACE all_records 


put the PC file records7 into the PS MAIL 
folder all_records. (The feature was available 
in the previous release of PS MAIL 6530.) 


More Attachments in PS MAIL 6530. Up to 
100 attachments can now be added to a mes- 
sage being created. Correspondents can add 
multiple attachments with the same keystroke 
by marking one or more messages from the 
SCAN screen or the new SHOW ATTACH- 
MENTS screen and then pressing the ADD key 
(F7). In PS MAIL TTY, as before, up to 100 
attachments can be added to the workspace, 
but they must be specified in separate 
commands. 


list on their local node. 


33 


34 


Character Mapping Option for PC Users. 

A new key word, TRANSLATE, followed by a 
language name, is used to identify the charac- 
ter set of a PC file that is to be added as an 
attachment. This is so that any non-ASCII 
national characters on the PC can be trans- 
lated to their equivalent codes on the Tandem 
system. The language can be any of those 
listed for the COPY command, described 
earlier. 


Highlights of PS MAIL TTY Enhancements 
Aside from supporting the features just 
described, PS MAIL TTY has many other new 
features. Users will also see more informative 
advice messages and an improved display of 
information. Only the major new features are 
discussed here, including: 


= Message ID ranges. 

=" FC command for changing the TO, CC, and 
SUBJECT lines. 

= New DIRECTORY command. 

= Enhanced SHOWFOLDERS command. 

# Enhanced READ command 

= New EDITMESSAGE command. 

= Enhanced CLEAR command. 

=" PS MAIL TTY commands in the start-up 
message. 

= BREAK key operation. 


Message ID Ranges. The COPY, DELETE, 
FILE, FORMAT, PRINT, and READ commands 
now support message ID ranges, a shorthand 
way to specify sequential message IDs without 
denoting each one separately. The range is 
defined by two message IDs separated with a 
slash (/). Message ID lists and ranges can be 
combined (e.g., PRINT 1/3, 5, 7/9). The com- 
mand line can contain as many message IDs 
and/or message ID ranges as will fit. 


PS MAIL TTY confirms action on a range 
with a single confirmation message per range. 
If some of the message IDs have already been 
deleted, it does not report that the message has 
been deleted. If the entire range is empty, it 
reports this in an advice message. 


FC Command for Changing the TO, CC, and 
SUBJECT Lines. Correspondents can now use 
the FC command to change the TO, CC, and 
SUBJECT lines when creating, forwarding, 
and replying to messages. This feature is use- 
ful for correcting typing errors and adding or 
deleting recipients. 


New DIRECTORY Command. This new 
command lets users show the directory of 
correspondent names on a given node. This 
command accepts a partial correspondent 
name and a node name to list matching corre- 
spondents. For example, DIRECTORY * 
@PARIS lists all of the correspondents on the 
PARIS node and DIRECTORY SMITH_+* lists 
all of the correspondents on the current node 
whose last names are SMITH. 


Enhanced SHOWFOLDERS Command. 
Users can now give the SHOWFOLDERS com- 
mand a partial folder name to list a subset of 
their folders. For example, SHOWFOLDERS 
P* lists all of the correspondent’s folders that 
start with the letter P. 


Enhanced READ Command. Users no longer 
need to give an additional READ command to 
read a single attachment to a message. READ 
automatically displays an attachment to a 
message if the message has only one attach- 
ment. (PS MAIL 6530 displays all of the 
attachments to a message.) 


New EDITMESSAGE Command. To continue 
to edit a message in the workspace, users can 
issue a new command, EDITMESSAGE. They 
can use this command, in place of CREATE- 
MAIL, to bypass the address prompts and 
begin editing the message immediately. 


Enhanced CLEAR Command. Now when 
users clear the workspace so that another mes- 
sage can be created, the workspace is automat- 
ically copied to the WASTEBASKET folder 
before it is cleared. (This feature was in the 
previous release of PS MAIL 6530.) 
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PS MAIL Commands in the Start-up 
Message. Users can now include PS MAIL 
commands as parameters when starting up 
PS MAIL TTY. For example, to start up 

PS MAIL and index the INBOX, the start-up 
message would be 


PSMAIL INDEX INBOX. 


BREAK Key Operation. The BREAK key can 
now be used to terminate the processing of a 
single command, multiple commands on a 
command line (e.g., PRINT; FILE reports), or 
an OBEY file containing commands. 


Highlights of PS MAIL 6530 Enhancements 
In addition to the new PS MAIL features 
already mentioned, PS MAIL 6530 has other 
new features that make it easier to use and 
more powerful. Three new screens and new 
function key capabilities have been added. The 
major new features are: 


= Persistent selection marks. 

= Previous screen function. 

= Last page function. 

= Increased EXTRAS availability. 

= Folder functions on the MAIN screen. 
= New SHOW ATTACHMENTS screen. 
= New READ ATTACHMENT screen. 

= Enhancements to creating mail. 


= Simultaneous filing and deleting of 
messages. 


Persistent Selection Marks. Previously, selec- 
tion marks on the MAIN and SCAN screens 
were erased after every action executed. To 
simplify multiple actions on an item, the 
marks now remain. Users can print and then 
delete messages, for example, by marking the 
messages, pressing the PRINT key, and then 
pressing the DELETE key. Also, to allow mul- 
tiple actions on distribution lists, users can 
select multiple items on the DISTRIBUTION 
LISTS and DISTRIBUTION NAMES screens. 


Previous Screen Function. F 16 now returns 
users to the previous screen, not the MAIN 
screen as before. 


Last Page Function. The shifted NEXT PAGE 
key now displays the last page of a screen. 


Increased EXTRAS Availability. The 
EXTRAS key (SF15) is now available from all 
screens except the LOGON and HELP screens. 


Folder Functions on the MAIN Screen. Users 
can now list a subset of their folders from the 
MAIN screen by typing a partial folder name 
on the options line and pressing F16. As 
before, this key also refreshes this screen. 

Correspondents can delete up to ten folders 
from the MAIN screen at once, instead of one 
at a time, by marking the folders and pressing 
the delete key. 

Multiple folders can also be selected and 
merged with the FILE key (F8) from this 
screen by marking the folders to be merged 
and typing the destination folder on the 
options line. The destination folder can be 
either a new or existing one. 


New SHOW ATTACHMENTS Screen. A new 
screen, SHOW ATTACHMENTS, accessed by 
pressing SF1 from the CREATE, READ, and 
SCAN screens, lists attachments to the work- 
space or to the message and presents the hier- 
archy of the attachments with level numbers. 
From the CREATE screen, SF1 shows attach- 
ments to the workspace; from the READ 
screen, it shows attachments to the message 
being read; and from the SCAN screen, it 
shows attachments to the selected message. 


New READ ATTACHMENT Screen. A new 
screen, READ ATTACHMENT, accessed by 
pressing F2 from the SHOW ATTACHMENTS 
screen, reads an attachment shown on the 
SHOW ATTACHMENTS screen. 
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ORDLINK allows | 

users to transfer | 
documents between 
various word processing 
programs or devices and 
the Tandem system. 


Enhancements to Creating Mail. In addition 
to the MAIN screen, the CREATE screen can 
now be accessed from the SCAN, READ, 
SHOW ATTACHMENTS, and READ ATTACH- 
MENTS screens. 

Also, a correspondent creating a message 
can now copy, format, or print the workspace 
directly from the CREATE screen (instead of 
filing the workspace to a folder first) with the 
COPY key (SF9), FORMAT key (SF8), or 
PRINT key (F9). 

Finally, the message in the workspace can be 
filed and sent using a single keystroke by typ- 
ing the folder name on the options line and 
pressing the SEND key (F11). 


Filing and Deleting Messages Simultaneously. 
Correspondents can now file and delete mes- 
sages in a single keystroke by typing the folder 
name on the options line and pressing the 
DELETE key (F6). 


WORDLINK 


WORDLINK, a new product available in the 
B40 software release, allows users to transfer 
documents between 
various word pro- 
cessing programs or 
devices and the 
Tandem system. 
WORDLINK has 
two parts: the 
WORDLINK batch 
gateway to 
TRANSFER and a 
collection of transla- 
tor programs. 

The batch gate- 
way is used to send documents from a word 
processor to any PS MAIL correspondent. For 
example, a correspondent using a Wang OIS 
or a Wang VS system can send a Wang docu- 
ment, via the WORDLINK batch gateway to 


TRANSFER, to a correspondent who is using a 
Tandem 6530 terminal. When the message is 
delivered, the translator programs convert the 
message from Wang format to a form accessi- 
ble by the recipient. (This step is completely 
transparent to the recipient.) 


How TRANSFER Stores WORDLINK 
Messages 

A document sent through the WORDLINK 
batch gateway to TRANSFER generally 
appears in the INBOX as a message attachment 
of type DOCUMENT and can be handled just 
as most other messages received. Unlike other 
types of messages, however, a message of type 
DOCUMENT is stored as an external object; 
i.e., it is external to the TRANSFER database 
but can still be accessed and used by 
TRANSFER. Translations of the message are 
stored as alternate external objects to the mes- 
sage, transparently attached to the primary 
external object. 


Message Translation upon Delivery 

Messages are translated when they arrive in 
the INBOX by the Translate-On-Delivery 
TRANSFER agent. (An agent is a TRANSFER 
program that is automatically invoked to han- 
dle messages on the correspondent’s behalf.) 
This agent can be configured through the 
TRANSFER Administrative Application 
(ADMIN) to automatically translate docu- 
ments into one or two specific formats. Once 
a message of type DOCUMENT is translated 
to a particular format, it need not be trans- 
lated again for any other user on that node. 
This is because only one copy of a message 
resides on the node, regardless of the number 
of recipients. 

Occasionally, a translation of the message 
may not be immediately available to a corre- 
spondent because the message has not yet been 
translated. This happens, for example, when 
an attempt to read the message is made imme- 
diately upon delivery or when the correspon- 
dent needs a translation that is not specified 
in the Translate-On-Delivery agent. In this 
case an advice message is displayed; the user 
can access the message after it has been 
translated. 
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The WORDLINK document translators cur- 
rently available are: 


« ANSI. 

® ASCII. 

® DISPLAY. 

= MultiMate. 


=" RFT (Revisable Format Text for 
Display Write2 or 3 on a PC). 


® Textpack (for IBM Displaywriter). 
=" TFORM. 
= Wang. 


The Wang, MultiMate, RFT, and Textpack 
translators are sold and licensed separately, so 
a node can be licensed to support just a few or 
all of these formats, depending on the users’ 
needs. The other translators are included with 
WORDLINK. 


Translation of WORDLINK Documents 
When a message of type DOCUMENT is read, 
printed, or added to the workspace for editing, 
PS MAIL automatically selects a DISPLAY 
translation of the document. This translation 
appears as though the document has been for- 
matted. Embedded printer attributes, such as 
pagination, boldfacing, and underlining, are 
not in the translation because they cannot be 
interpreted by the terminal. 

When the message is edited as an attach- 
ment to the workspace, formatted to a printer, 
or copied to a GUARDIAN 90 or PC file, 

PS MAIL selects a translation containing for- 
matting commands. For most users of Tandem 
terminals, the translated format is TFORM. As 
the formatting information remains intact, the 
recipient may, for example, copy a message 
containing MultiMate commands and escape 
codes to a GUARDIAN 90 file in TFORM for- 
mat, add text and TFORM commands to the 
file, and then use TFORM to print the file to a 
Tandem printer. 


PS MAIL Enhancements for 

WORDLINK Documents 

Most of PS MAIL’s support for WORDLINK 
documents is transparent to users; however, 
some PS MAIL command options specific to 
this new product have been added. When cor- 
respondents add a WORDLINK attachment to 
the workspace, the document format (such as 
MultiMate) must be specified. The attach- 
ment is then added to the workspace as type 
DOCUMENT. 

The document format can be specified, but 
is not required, when an attachment is copied 
to a GUARDIAN 90 or PC file. The document 
format is implicit when correspondents edit an 
attachment of type DOCUMENT in the work- 
space and when they read, format, and print 
these messages. 


Adding WORDLINK Documents as 
Attachments. A new keyword, AS, followed 
by the document format tells TRANSFER the 
format of the attachment to be added. The 
document format is one of those listed earlier. 
From PS MAIL TTY, for example, 


ADDATTACHMENT results AS TFORM 


adds the file results to the workspace as a 
TFORM document. 
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many alternative 
language versions and 
corresponding character 
maps to its international 
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Printing and Formatting WORDLINK 
Documents. A message of type DOCUMENT 
is printed or formatted just as any other mes- 
sage received. When the PRINT command 
prints a message of type DOCUMENT, a 
DISPLAY translation of the message is printed. 
When the FORMAT command prints a mes- 
sage of this type under the control of the 
TFORM formatter, a TFORM format transla- 
tion of the document is given to TFORM to 
format. When the TGAL formatter is selected, 
a DISPLAY format translation of the message 
is given to TGAL to format. 


Copying WORDLINK Documents to a File. 
The new optional keyword, AS, followed by 
the document format, tells TRANSFER which 
translation of the message to copy. From 

PS MAIL TTY, for example, 


COPY 1 PC: forcasts AS MULTIMATE 


copies a MultiMate translation of the message 
to a PC file named forcasts. 

If no document format is specified, 
PS MAIL copies a TFORM translation when 
the default formatter 
is TFORM; other- 
wise, it copies a 
DISPLAY transla- 
tion. TFORM trans- 
lations add special 
TFORM commands 
so that when the 
document is format- 
ted, the envelope 
(header) information 
is printed on a sepa- 
rate page. Separate 
messages copied to the same file each start on 
a new page, and formatting commands used in 
one attachment do not affect the next one. 


National Language Support 


PS MAIL now provides many alternative lan- 
guage versions and corresponding character 
maps to its international users. An unlimited 
number of the PS MAIL language versions can 
exist on a single TRANSFER system. Currently 
PS MAIL for 6530 terminals is available in 
Danish, Finnish, French, German, Hebrew, 
Norwegian, Spanish, and Swedish. PS MAIL 
for 3270 terminals is available in Danish, 
Finnish, Norwegian, and Swedish. And 
finally, PS MAIL for TTY terminals is avail- 
able in Finnish. Additional language versions 
will be supplied as demand requires. The fol- 
lowing sections present the user’s view of these 
alternative language versions, how the alterna- 
tive language text is stored, and how a single 
TRANSFER system supports these multiple 
language versions. 


The User’s View 

National language support allows help text, 
advice messages, prompts in PS MAIL TTY, 
and screens in PS MAIL 6530 to appear in the 
correspondent’s language. Correspondent 
names appear as they would normally in the 
native language; for example, a Danish recipi- 
ent of a message sent through PS MAIL, whose 
name contains “g,” can now be registered and 
referenced by the correct name. The special 
folder names, INBOX, OUTLOG, and WASTE- 
BASKET, have names that are meaningful 

for each language on the system. Finally, 
TRANSFER system messages, such as 
acknowledgments for certified mail, are also 
translated. 


Text Storage 

The text generated by PS MAIL TTY, such as 
command names and help text, is stored in its 
own command and message files. The screen 
text for PS MAIL 6530 is stored in a special 
TRANSFER database. The text generated by 
TRANSFER, used by all PS MAIL user inter- 
faces, such as the special folder names and 
TRANSFER system messages, is also stored in 
a special TRANSFER database. 
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PS MAIL Glossary 


Attachment 


A message or a file (such as a GUARDIAN 90 file 
or facsimile document) that is attached to another 
message. 


Character map 


A set of codes that establishes a correspondence 
between the native form of a character and a base 
character set. A base character set is the set of all 
characters that TRANSFER stores and makes 
available for text. In effect, this map is a set of 
rules for encoding or representing characters in that 
set. It determines how characters entered from the 
keyboard are interpreted, and how characters out- 
put to various devices are generated by 
TRANSFER. 


Correspondent 


A PS MAIL user who creates, sends, receives, and 
handles mail messages. 


Directory 


A list of all correspondents on a node. 


Distribution list 


A list of recipients to whom messages can be sent. 
Distribution lists allow PS MAIL users to specify 
many correspondents with just one reference. 


Envelope 


The information that identifies a message. It con- 
tains the name of the sender, the message type, the 
subject of the message, and the date and time the 
message was sent. When a message is read, the 
envelope appears just before the text of the 
message. 


Folder 


An area where messages are stored. Correspon- 
dents can organize their mail by creating folders, 
storing messages in them, and deleting them when 
they’re no longer needed. Folders are private; no 
one but their owners can create, view, use, or delete 
them. Each PS MAIL correspondent owns three 
special permanent folders: INBOX, OUTLOG, 
and WASTEBASKET. 


INBOX 


Messages received by the correspondent are auto- 
matically filed in this folder. 


Message type 


A designation that describes how the message was 
created. It is displayed in the message envelope. 
Some of these types are: DATA, DOCUMENT, 
FAX, FORWARD, ORIGINAL, PCDATA, 
REPLY, TEXT, and TTEXT. 


Node 


A Tandem computer system that is part of a net- 
work of other Tandem systems. 


OUTLOG 


This folder contains a record of messages sent by 
the correspondent. These messages are generally 
filed for just 24 hours. 


Profile 


A portion of the TRANSFER database that con- 
tains the correspondent’s password and default 
information such as the default printer and 
formatter. 


PS MAIL contact 


A person in an organization who is responsible for 
general administrative assistance to PS MAIL 
users. 


WASTEBASKET 


This folder contains messages deleted from other 
folders and is emptied when the correspondent exits 
PS MAIL. 


Workspace 


A temporary area where PS MAIL saves the 
address, message text, and attachments to the mes- 
sage that is being created. The workspace remains 
intact until the correspondent sends the message, 
explicitly clears the workspace, or exits PS MAIL. 


Multilingual Systems 

Generally, when a correspondent starts 

PS MAIL, TRANSFER uses the default lan- 
guage and character map configured for the 
node. When a correspondent needs to start 
PS MAIL in an alternate language and charac- 
ter map, a front-end program specifying the 
alternate language and character map is used 
to start TRANSFER and PS MAIL. 


Conclusion 


The B40 release of PS MAIL extends the capa- 
bilities for using electronic mail in several 
ways. First, the PS MAIL user interface is 
more powerful and flexible, so that users can 
handle their mail more efficiently. Second, 


PS MAIL now allows users of word processors 
on PCs or stand-alone systems to exchange 
documents with other PS MAIL users through 
WORDLINK, so that users can use their nor- 
mal word processor. Third, PS MAIL can be 
converted into a number of foreign languages 
and character sets, so that users can handle 
their mail in their native language. These 
enhancements make the PS MAIL products 
more attractive to current and potential cus- 
tomers, and more useful for Tandem 
employees. 
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andem customers need a 
variety of up-to-date product 
information to use their 
Tandem equipment effec- 
tively. Until recently, their 
primary means to obtain this 
information was by contact- 
ing their local systems analyst or sales repre- 
sentative. The analysts have several tools at 
their disposal to answer the query: Tandem’s 
internal mail network, where information 
from other analysts is requested; an on-line 
internal information system, where prior que- 
ries are archived and indexed for easy access; 
or any of the other internally accessible collec- 
tions of data. 

Now, customers can access a similar collec- 
tion of information directly through Tandem’s 
new on-line Customer Information Service 
(CIS). In addition to information retrieval, 
customers can share their knowledge and expe- 
rience through CIS’s information exchange 
facility. 


Why CIS? 


A customer information service, as the name 
implies, puts information into the hands of the 
customer. With the levels of interpretation 
removed, the customer has direct access to 
information. 


Customer Information Service 


An important reason for such a service is 
the immediate availability of the information. 
Customers need the information when they say 
they need it, not the next day or the next week. 
If a problem occurs at 4 A.M., that’s when the 
answer is needed. Without the delays associ- 
ated with phoning someone for information 
(who must research it and phone back), an on- 
line information system provides round-the- 
clock accessibility. 

Further, information which is centrally 
maintained is frequently more up-to-date and 
consistent than otherwise possible. 

Customers can expect this service to help 
solve many of their day-to-day problems: 


® Verifying the installation of the most recent 
emergency bug fixes (EBFs). 


® Searching for problems similar to those 
being experienced. 


= Searching Tandem publications (such as the 
Tandem Systems Review) for applications/ 
operations suggestions. 

= Exchanging ideas or information about soft- 
ware or hardware products with other Tandem 
customers. (Data placed into the information 
exchange expires after 30 days, though partic- 
ularly useful information is collected into an 
information archive.) 


= Locating classes that fit the customer’s edu- 
cational and scheduling needs. 


Al 
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Several information systems predate CIS. 
The earliest was a system designed for Tandem 
analysts only. It was used by field analysts to 
search for previously submitted questions 
and answers, and by customers to access 
SOFTDOCs and other information. The system 
that followed was designed to ease maintain- 
ability and to keep the information up-to-date. 


Features 


The features provided on CIS cover a wide 
range of areas, from directories and schedules 
to general information about software. As 
presently configured, the CIS system supports 
the following features: 


« Alliance, a directory of companies that are 
members of Tandem’s Alliance program. This 
feature allows the customer to search for Alli- 
ance members by name, product name, or 
area of expertise. For example, a customer 
can search for CIM and find all members 
with computer-integrated manufacturing 
experience. 


® Classes, schedules for Tandem education 
classes. With this feature, a customer can 
search current class schedules by class name 
(or fragment of the name, e.g., TMF), class 
code, class location, class region (North 
America, Europe, Pacific), or date range. 
For example, with date range, one can search 
for all TAL classes between January 15 and 
March 2. 


" EBF information. This feature gives cus- 
tomers access to information about EBFs 
(reported bugs for which a fix is available). 
EBFs can be searched for by Tandem product 
number, product name (such as DP2-related 
problems), HOTSTUFF number, or by some 
symptoms (such as CPU crash or directory 
corruption). 

= Electronic store. This feature allows cus- 
tomers to peruse the items in the electronic 
store, make selections, submit a purchase 
order number, and be automatically billed for 
the selections. Software manuals are currently 
available. Access to this feature can be 
restricted to certain individuals at a company 
site. 


= Help. With this feature a customer can find 
which features are installed on the system, 
what they are, and how to use them. This on- 
line help facility is available to all users. If the 
customer is familiar with the standard Tandem 
command interpreter (COMINT) syntax, they 
should have no difficulty using the CIS system. 


« Information exchange. With this feature a 
customer can post and read notices on various 
topics. Users can add themselves to special 
interest groups and post notices to other mem- 
bers of such groups. (A FORTRAN user’s 
group can exchange information about 
FORTRAN and special applications using it.) 
This facility allows customers to share their 
experiences and gather valuable help from 
other users. 


= Menu. With this option, features are 
invoked by selection from a menu of allow- 
able choices. This feature coexists with the 
command-driven interface. Customers can 
access features by their names or by their 
menu item numbers. 


= News. This feature allows the customer to 
view news about the CIS system. Articles 
cover enhancements, the addition of new data- 
bases, new classes, or any other items related 
to CIS and its use. 


« Press releases. With this feature a customer 
can search Tandem press releases by date, 
product name, or by any string information. 
(For example, a customer could search for a 
press release in which Kentucky Fried Chicken 
was mentioned.) 


=" PML, product maintenance levels. This is an 
up-to-date listing of products supported by 
Tandem, dates the product will be supported, 
and the level of support available. 


® SOFTDOCs, Tandem software documenta- 
tion shipped on the product tape. This feature 
gives the customer the ability to search existing 
SOFTDOCs for information. The customer can 
search for SOFTDOCs by Tandem product 
number, product name (such as DP2), or by 
any string information that might appear in a 
SOFTDOC. (For example, a customer can 
search for all SOFTDOCs mentioning memory.) 


= Suggestion box. This feature allows cus- 
tomers to submit suggestions and comments 
about the CIS system and its performance. 


=" Tandem Systems Review. With this feature 
customers can search Jandem Systems Review 
articles for information. They can search 
articles by product names (such as VLX), 
subjects (such as security), or by any other 
string information. 


Refer to Figures 1, 2, and 3 for more informa- 
tion on CIS’s features. 


Accessing CIS 


CIS is currently available to customers in two 
ways: through dial-up ports available at the 
Tandem Sunnyvale office and through a 
broader-based CompuServe network to which 
CIS is connected. 

Customers choosing to access the CIS sys- 
tem directly can call a Sunnyvale, California, 
telephone number and be connected to the 
system. The dial-up ports in Sunnyvale are 
available to any customer. These ports support 
300- or 1200-baud terminals. 


Figure 1 


CiS$ 2> help 
The following features are installed on the CIS system: 


ALLIANCE CLASSES 

EBF_LIST EBF_SEARCH 

EBF_SUMMARY HELP 

INFO_EXCHANGE MENU 

NEWS PRESS_RELEASES 

PML PRODUCT_MAINTENANCE_LEVELS 
SOFTDOC_B30_LIST SOFTDOC_B30_SEARCH 
SOFTDOC_B40_LIST SOFTDOC_B40_SEARCH 
SUGGESTION_BOX SYSTEMS_REVIEW 
TANDEM_STORE 


For more information enter: HELP ALL 
For more detailed information about a specific feature 
enter: HELP featurename 


Figure 2 


CIS 3> help atl 


The following features are available on this system. They may be invoked by 
entering the feature name as shown. (Additional help may be obtained for a 
specific feature by entering its name after the word HELP) EXAMPLE: 


HELP ALL (will display this information) 


ALLIANCE - searches for Tandem Alliance Directory information 

CLASSES - searches Tandem class schedule information 

EBF_LIST - displays EBF HOTSTUFFs, and EBF SOFTDOCs 

EBF_SEARCH - searches EBF HOTSTUFFs, and EBF SOFTDOCs 

EBF_SUMMARY - displays Emergency Bug Fix summary information 

INFO_EXCHANGE - allows users to exchange ideas 

MENU - allows menu-selection access to features 

NEWS - displays current Tandem or CIS news 

PML - alias for PRODUCT_MAINTENANCE_LEVELS 

PRESS_RELEASES - searches Tandem press releases 

PRODUCT_MAINTENANCE_LEVELS - defines software product maintenance levels 

SOFTDOC_B30_LIST - displays B30 SOFTDOCs for individual products 

SOFTDOC_B30_SEARCH - searches B30 SOFTDOCs 

SOFTDOC_B40_LIST - displays B40 SOFTDOCs for individual products 

SOFTDOC_B40_SEARCH - searches B40 SOFTDOCs 

SUGGESTION_BOX - allows user to enter comments or suggestions 

SYSTEMS_REVIEW - searches Tandem Systems Review articles 

TANDEM_STORE - an electronic store that allows ordering of selected 
products 


Figure 1. Figure 2. 

Initial HELP screen HELP summary screen 

showing all features. with features described. 
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Figure 3 


CIS 4> help alliance 


The Tandem Alliance Directory contains information on Tandem Alliance 


companies. This feature allows the user to search for information by 
company name or by the subject area (example: CIM will yield all 
Alliance members with Computer Integrated Manufacturing products). 
This feature is accessed by entering ALLIANCE. 


CompuServe, a subscriber-based network, 


Figure 3. A : 

Detailed HELP informo- provides dial-up access from several hundred 
tion for an individual locations throughout the United States, Can- 
feature. ada, Europe, and the Pacific. Customers sim- 
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ply dial a local number and log onto the 
CompuServe network. They are then con- 
nected to the CIS system in Sunnyvale. In 
addition, the CompuServe network can be 
accessed via “bridges” from other network 
services that provide X.25 access (see 
Figure 4). 

Regardless of the path chosen, once users 
have accessed the CIS system, they can log 
onto it just as they would any Tandem system, 
through the command interpreter. Individual 
features are invoked by entering their names at 
the CIS prompt. A list of available features is 


viewed by entering HELP (see Figure !). 

A command of HELP ALL (see Figure 2) gives 
a brief description of each feature. For addi- 
tional information on each feature, enter 
HELP followed by the feature name (see 
Figure 3). 

Each feature on the CIS system can be 
accessed and controlled separately, making it 
possible for one feature to be updated without 
affecting others. This benefits the user by 
keeping the most features available at any 
given time. The system also lets the users 
know the status of any disabled feature. For 
instance, if a new database were to be 
installed for the classes feature, the system 
operator would make that feature unavailable 
during the installation. If a user attempted to 
access it, the system would display the follow- 
ing message: 


CLASSES 
NAMED FEATURE WILL BE 
UNAVAILABLE UNTIL 14:01 15-SEP-87 
(21:01 15-SEP-87 GMT) 


Customers have the option of giving their 
employees complete access to all features or of 
limiting access on a user-by-user basis. For 
example, a supervisor at a customer site may 
be the only person licensed to access an extra- 
cost feature. This degree of control will 
become increasingly important as new features 
are added which could result in additional 
charges (see electronic store under “‘Features”’). 

The first-time user might find the new-user 
information helpful. To access it, simply enter 
NEW_USER at the CIS prompt. Most users 
become familiar with the CIS system after 
their first or second session. 


Future Directions for CIS 


The CIS system was not intended as a static 
service; it was designed with a modular archi- 
tecture to allow for expansion as new needs 
arise. CIS will change and grow as customers’ 
needs for information change. 

One feature currently under development 
provides Tandem product report (TPR) status 
information. (TPRs are initiated by the cus- 
tomer and include suggestions for enhance- 
ments to products and problems encountered 
with the products.) This feature will allow 
customers to view the current status of their 
own TPRs, but not those submitted by other 
customers. 


Signing Up for CIS 


CIS is currently available for use by Tandem 
customers through their local Tandem analyst 
or salesperson. Since laws and regulations 
affecting the use of CIS vary from country to 
country, the local sales office should be que- 
ried for specific ordering procedures. 

The basic subscription gives a customer 
access to CIS through the Sunnyvale dial-up 
modems. There are other options available, in 
addition to the basic subscription, that allow 
customers several methods of access via the 
CompuServe network. 

Comments or suggestions for ways to 
improve the product are always welcome. 


Joe Massucco joined Tandem’s Corporate Manufacturing Tech- 
nology Software Support Group in 1981 with over 15 years of 
experience in applications and system-level software. While in 
Manufacturing, he designed the Tandem contro! software for the 
NonStop TXP board test system. He joined the Field Productivity 
Programs Group in 1986 to design and implement the CIS 
system. 
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Figure 4. 


Customer access to the 
Customer Information 
Service. The various 
methods of access are 
represented by the follow- 
ing: (a) direct dial-up 


access to the Sunnyvale, 
California, number; 

(b) dial-up access through 
CompuServe; (c) dial-up 
access through other 
public data networks, 


such as INFONET 
(internationally); 


(ad) X.25 access using a 


terminal connected to 
a customer’s Tandem 
system. 


Tandem’s Software 
Support Plan 


andem’s Software Support 
Plan was developed to give 
Tandem customers a better 
understanding of how sup-_ 
port is provided. It represents 
a strengthening of definition 
of Tandem’s support plans 
for software and an improvement in support 
practices.’ 


Software Releases 


There are two types of software release: 
unplanned and planned. 

An unplanned release is produced on 
demand in response to an emergency 
situation. Because of its emergency nature, an 
unplanned release is called an Emergency Bug 
Fix (EBF). It typically involves a single prod- 
uct and is distributed and installed in the 
smallest possible package, i.e., the smallest 
number of files required to fix the problem. 
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As its name implies, a planned release is a 
planned event. The two types of planned 
release have different criteria. In the base 
release: 


# The foundation products have undergone a 
major change.’ 

= Any product is eligible for submittal without 
restriction. 

® The release is based on content (i.e., it is not 
tested and distributed until all of the planned 
content is present). 


= Base releases occur approximately every 
18 months. 
= The release, as a whole, is beta-tested. 


® The release ID indicates a new base version 
(e.g., BOO, C00, etc.). 


In the incremental release: 


® The foundation products have not undergone 
a major change. 


= The set of products eligible for submittal is 
restricted; candidates for eligibility are scruti- 
nized for risk of regressions. 


= This release is based on the schedule (i.e., it 
is tested and distributed on a schedule; 
planned content that is not ready must wait 
for the next planned release). 


?The Software Support Plan is not intended to conflict with any license 
agreements that may currently be in effect. The plan itself may be amended 
periodically. Customers will always receive written notification of such changes 
at least three months prior to their effective adoption date. 


?Foundation products are those which would appear at, or near, the root of a 
tree showing the execution dependencies of Tandem products in relation to the 
majority of customer applications. Examples of foundation products are 
GUARDIAN, EXPAND, TMF, and PATHWAY. 


= Incremental releases occur approximately 
every six months. 


« The release, as a whole, will not be 
beta-tested. 


= The release ID indicates only a revision to 
the base version (e.g., the B10, B20, and B30 
revisions of the B00 release). 


New software products and significant 
enhancements to existing products undergo 
beta testing before general distribution in any 
planned release. New products/ features intro- 
duced in a base release are beta-tested in con- 
junction with the release as a whole; new 
products/features introduced in an incremen- 
tal release are beta-tested individually, before 
inclusion in the release. 

All products participating in a planned 
release are tested as a unit and should be 
installed as a unit. Mixing products or files 
from different planned releases on a single 
system may give unpredictable results. 

Each planned release will be announced at 
least six weeks before it is available. 


Shipping Planned Releases 
to Customers 


Planned releases are always delivered to cus- 
tomers on a Site Update Tape (SUT). A SUT 
contains all standard software products, plus 
those optional software products that a given 
site is entitled to receive. Three different 
events can trigger the shipment of a SUT: 


1. The shipment of a new system is accompa- 
nied by a SUT containing the most recent 
planned release within the most recent 
base series. 


2. A new order by an existing customer for an 
optional software product is filled with a 
SUT containing the ordered product. The 
SUT contains the most recent planned 
release within the most recent base series. 


3. A request for a planned release by an exist- 
ing customer is filled by a SUT containing 
the most recent planned release for the 
requested base series. 


Software Support 


Overview 

Tandem’s support commitments pertain to 
systems entitled to software maintenance in 
accordance with a Tandem software agree- 
ment. Several areas are involved: 


= The release states for planned releases. 


=" The Product Maintenance Levels of soft- 
ware products. 


= The severity levels of reported problems/ 
enhancements. 


Release States. A given release is either sup- 
ported or unsupported. 

An unsupported release is one for which 
Tandem provides support on a “‘best effort” 
fee basis, with no guarantee that a problem 
can, or will, be fixed. Charges for support of 
such releases are assessed in accordance with 
the Analyst Services Agreement. 

In a supported release, Tandem provides 
defect support in accordance with a Tandem 
software agreement. From its initial date of 
availability, each planned release is supported 
for a minimum of 15 (typically 18) months. 
When a new planned release is announced, 
definitive dates for the support periods of pre- 
vious releases will be included in the 
announcement. The expiration date for any 
planned release will be announced to cus- 
tomers at least six months before the release 
becomes unsupported. 

The state of any given release (supported or 
unsupported) is unchanged by the application 
of any modification (e.g., an EBF) supplied by 
Tandem. 


*In order to make a correlation to licensing agreements, the contract terms 
“Current Release” and ‘‘Noncurrent Release”? may be generally substituted for 
the terms ‘Supported Release” and “Unsupported Release” that are used in 
this article. 
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Table 1. 
Tandem’s Product Maintenance Levels (PMLs). 
Level Description 


Active The product is distributed in planned releases. The 
product is still evolving functionally and is actively 
maintained. 

Mature The product is distributed in planned releases. The 
product is functionally mature and reliably stable. 
New versions of the product are produced only 
when necessary to solve significant problems. 

Qbsolete The product is no longer supported, and it ceases 
to participate in planned releases. References to 
the product will be removed from the price list and 
other literature. 

Table 2. 

Severity levels (SLs). 

Level Description 

0 Can tolerate the situation indefinitely. 

1 Can tolerate the situation, but expect a solution 

eventually. 

2 Can tolerate the situation, but not for long. Need a 

solution. 

3 Cannot tolerate the situation. A solution urgently 

needed. 


Product Maintenance Levels. There are 
varying degrees of maintenance activity for 
Tandem’s software products. Certain products 
receive less maintenance effort than others, 
based on the maturity of the product, the size 
of its user community, or the existence of a 
preferred replacement product. Eventually, 
after sufficient customer notification, Tandem 
may want to withdraw all maintenance for 
certain products. 

Each Tandem software product is assigned 
to one of three Product Maintenance Levels 
(PMLs). The PML of a product is a descrip- 
tion of its current maintenance status. At any 
given time, a product is assigned to only one 
PML. PMLs are defined in Table 1. 


The PML for each product is included in the 
Release Notes for each planned release, and in 
machine-readable form on the SUT. Such 
information reflects the PMLs at the time of 
initial release and may not be current at a later 
date. 

A current list of PMLs is maintained on the 
Customer Information Service (CIS), which is 
available by subscription. An accompanying 
article, ““Customer Information Service,” 
describes the features of the CIS system. 

An announcement of a change to the PML 
of a product will be in terms of a calendar 
date and will be announced at least six months 
before the change is effective. Notification will 
be at least 12 months in advance for a product 
moving to the obsolete category. 


Severity Levels. Problems or enhancement 
requests are assigned a severity level (SL) 
dependent on the customer’s degree of need 
for a solution. (See Table 2.) 

The severity level is defined by two 
components: 


® The consequences of the problem. 
= The urgency of need for a solution. 


These two components are not always in direct 
proportion to one another. There are many 
problems with dire consequences that are not 
urgently in need of a solution. Conversely, 
there is a smaller set of problems whose conse- 
quences are tolerable, but whose urgency for a 
solution is great. Assignment of severity level 
requires subjective judgment. It is critical that 
both the Tandem analyst and the customer 
agree on the severity level when the report is 
submitted, keeping in mind that if everything 
is an emergency, then nothing is. 

The severity level of a given problem is 
strictly a function of the problem and is unre- 
lated to its solution. Once established, the 
severity level in the Tandem Product Report 
(TPR), as well as Tandem’s commitment to fix 
the problem in a future release, is unchanged 
by the presence of a temporary solution. 

Tandem’s support commitment is defined in 
Table 3. 


Solution Alternatives 
Any problem has two basic solutions: fix it or 
work around it. 

A single fix is based on a single version of a 
product, but it may be applicable to multiple 
supported releases, each containing a different 
version of the faulty product. Normally, the 
deliverable form of a fix for a supported 
release is based on the highest version of the 
faulty product component that is compatible 
with the reported version. 

A “workaround” instead of a fix may be 
indicated if the workaround ensures that: 


= Delivery is more timely. 
« Implementation is less complex. 
« Reliability is more certain. 


A workaround in lieu of a fix must be 
acceptable to the customer, and it must have 
the effect of reducing the severity to a level 
that the customer can tolerate until the prob- 
lem is permanently fixed in a planned release. 


Permanent vs. Temporary Solutions. There 
are several ways that Tandem might provide 
relief from a problem. A temporary solution 
might be a workaround. This option results in 
no changes to software supplied by Tandem. 

Alternatively, a customer could replace the 
entire faulty product with a newer version 
from a more recent planned release or replace 
the minimum number of files required to 
solve the problem. The source of the replace- 
ment file(s) might be either: 


= A more recent planned release containing 
the desired fix. 

= An EBF based on a more recent version of 
the product. 


= An EBF based on the reported version of the 
product. 


For a permanent solution, a customer could 
install an entire, more recent, planned release 
containing the desired fix. 


Table 3. 
Tandem’s support commitment, defined as a function of release state, 
Product Maintenance Level, and severity level. 


Product Maintenance Level 


Active Mature Obsolete 
SL SL 

Support component Release state 0123 0123 Any SL 
investigate a Supported YYYY NNYY F 
problem in the 
reported release Unsupported FFFF FFFF F 
Deliver a temporary solution Supported NNYY NNNY F 
in a form compatible with 
the reported release Unsupported FPE-PF FFFF F 
Implement a Supported YYYY NNYY N 
permanent fix ina 
future planned release Unsupported YYYY NNYY N 
Consider an enhancement Supported YYYY NNNN N 
request for implementation 
in a future planned release Unsupported YYYY NNNN N 


Y = Yes, covered by software agreement 
N = No, not covered by software agreement 
F = Fee based on Analyst Services Agreement 


Randy Baker joined Tandem in 1983 after a 16-year career with 
another vendor. Initially he ran a task force to establish a support 
strategy for Tandem and later became manager of several sup- 
port organizations. In 1984, Randy was named director of Cus- 
tomer Support for Tandem. 


Dennis McEvoy co-authored the original release of GUARDIAN 
and later became manager of the Operating Systems Software 
Group. He helped establish Tandem in 1974. In February 1981 
Dennis was named manager of Software Development and, 
within two years, was appointed vice president of that group. 
Under his direction, our software development strategy con- 
tinues to evolve to address the needs of customers and to create 
state-of-the-art products. 
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